Scalable high-performance interactive real-time media architectures for virtual desktop environments

ABSTRACT

System for providing interactive two-way audio in desktop virtualization environment, the desktop virtualization environment comprising a desktop virtualization server computer and desktop virtualization client endpoint device with associated microphone element. The system incorporates instance of server software for running on a desktop virtualization server and providing interactive user interface functions to associated desktop virtualization client endpoint device; and instance of endpoint software executing on the desktop virtualization endpoint device including a network port, the instance of endpoint software receiving an incoming real-time video stream from the network port and providing at least real-time and display functions on the desktop virtualization client endpoint device. In the system, the desktop virtualization client endpoint is configured to: accept real-time audio input from a microphone element associated with the desktop virtualization client endpoint; and provide an outgoing real-time compressed audio stream to the network port responsive to the real-time video input from the microphone element.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

The present patent application relies upon, claims the benefit ofpriority under 35 U.S.C. 120 from, and is a continuation of U.S. patentapplication Ser. No. 12/828,252, now issued as U.S. Pat. No. 8,949,316,which claims the benefit of priority under 35 U.S.C. 119 from U.S.provisional patent application Ser. No. 61/339,834, filed Mar. 9, 2010,both of which are incorporated by reference herein in their entirety.This patent application is also related to commonly owned U.S. patentapplication Ser. No. 12/828,253, now issued as U.S. Pat. No. 8,869,141,and U.S. patent application Ser. No. 12/828,249, now issued as U.S. Pat.No. 8,799,362, which are all incorporated by reference herein in theirentirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present application pertains to Virtual Desktop Infrastructure(“VDI”) and Virtual Application Infrastructure (“VAI”), and morespecifically to real-time communication among thin-terminals, and inparticular their operation and use in virtualization, remote terminal,and mobile device environments.

2. Description of the Related Art

Many organizations are moving away from traditional PC-based desktoparchitectures in favor of Virtual Desktop Infrastructure (VDI) andVirtual Application Infrastructure (VAI). These enable knowledge workersto access software applications and desktops located in data centersfrom anywhere that is reachable over a network using various types ofcomputers, mobile devices, and low-power terminals.

Virtual Desktop Infrastructure (VDI) is an adaptation of the currentlypredominant commercial technology trend of platform virtualization(commercially referred to as “machine virtualization”). Abstractly,platform virtualization allows an operating system to run with a degreeof separation (often over a network) from the underlying physicalcomputing platform. In practical terms, a software implementation oremulation of a computer is used to execute programs in the same wayprograms would execute on a hardware computer and its operating system.The software implementation or emulation of a computer in such a contextis referred to as a “virtual machine” (VM). There are many adaptations,extensions, and usage nuances of the virtualization concept incomputing; for example, see the wiki page on the topic(http://en.wikipedia.org/wiki/Virtualization). Many of these havecommercial implementations that can provide (or claim to provide)substantially improved efficiency, maintenance, reliability, and accessto computer users within an enterprise.

Among the trends in the vast contemporary virtualization marketplace isthe notion of Virtual Desktop Infrastructure (VDI), wherein desktopoperating systems and applications execute on virtual machines (VMS)residing on a server or group of servers, computing cloud, etc. In thecommercial enterprise computing industry, a desktop operating systemexecuting in this fashion has been termed a “virtual desktop”(http://www.vmware.com/pdf/virtual_desktop_infrastructure_wp.pdf, forexample). A related concept is that of desktop virtualization. Accepteddefinitions can be readily found, for example in Wikipedia entries suchas these:

Desktop virtualization is the concept of separating a personal computerdesktop environment from the physical machine through a client-servercomputing model. The resulting “virtualized” desktop is stored on aremote central server, instead of on the local storage of a remoteclient; thus, when users work from their remote desktop client, all ofthe programs, applications, processes, and data used are kept and runcentrally, allowing users to access their desktops on any capabledevice, such as a traditional personal computer, notebook computer,smartphone, or thin client. (fromhttp://en.wikipedia.org/wiki/Desktop_virtualization, visited Mar. 12010.)

Virtual desktop infrastructure (VDI) is the server computing modelenabling desktop virtualization, encompassing the hardware and softwaresystems required to support the virtualized environment. (fromhttp://en.wikipedia.org/wiki/Desktop_virtualization, visited Mar. 12010.)

VDI arrangements employ a client/server model in the sense that endpointsoftware and devices render graphical display as instructed by softwareapplications running on one or more other computers (such as servers),and further in which endpoint software and devices collect and forwardinput events and data from users and provide these to those softwareapplications running on the one or more other computers. In many ways,VDI resembles the X Window System architecture from the mid 1980'sthrough mid 1990's.

Among the advantages provided by desktop virtualization and VDI are thatsignificant portions of the software environment can be centrallyoperated, maintained, patched, upgraded, backed-up, protected, andmanaged. Subsequently, the staffing hours required by IT organizationscan be considerably reduced, and higher levels of performance andavailability and reliability can be obtained. Additionally, theadministration and management tasks at the desktop reduce considerably.Further, remaining at the desktop are far fewer functions needing farless computing power. The resulting amount of software needed at theendpoint shrinks considerably.

With this established, some brief remarks on terminology are nowprovided to prevent confusion between traditional long-standing conceptsand conventions in computer science and increasingly commonplace VDIterminology:

1. The far-smaller article or instance of software executing at theendpoint would historically be referred to as a “thin client.” However,this previously established terminology has now become superseded asprominent VDI terminal manufacturers use the term “thin client” as afunctional and product name for associated types of end terminalhardware. As a result, those new to computing accordingly interpret theterm “thin client” as hardware rather than software as it would behistorically. In place of the historical terminology, the newterminology “terminal client” has become the VDI terminology foruser-side software executing strictly on a remote terminal. Accordingly,herein the VDI terminology “terminal client” will be employed.

2. Adding to the potential confusion, what would otherwise be theassociated complementary term of “terminal server” has come into usageas the term for server hardware and background server operating systemexecuting on server hardware or other higher-performance and/orcentralized computing system. In VDI terminology, the complementaryinstance of software running at a server or other type of computer andassociated (in a client-server sense) with a given “terminal client” iscalled a “virtual machine.” Although the term “virtual machine” has itsown historical usage and in other types of virtualization technology,herein the aforementioned VDI terminology will be employed.

Of key importance in the mass-acceptance of VDI is that fact that theperformance of most applications operating in a VDI environment isnearly at parity with, if not exceeding, that of the tradition desktopcomputing world. These and many other economic and operationaladvantages motivate a strong drive towards VDI inside the modernenterprise computing environment.

However, no degradation in performance is actually not an accurate orcomplete story. Although most desktop computing applications do well orbetter operating in a VDI environment, in fact some applications arefunctionally and structurally not suited for even adequate performancein a standard VDI environment. Among these, and perhaps the mostimportant among them, are real-time communications applications such asVoIP, video conferencing, and some types of high-performance telemetry(for example as in remote medical monitoring). Another type of exceptionis that of advanced data visualization. In each of these exceptions, thevolume of data communications between the computational portion ofapplications executing at the server and rendering portion ofapplications executing at the endpoint can be exceedingly high and/orsignificantly adversely affected by delay and jitter effect inherent inthe networking provided by VDI environments.

Thus, it would be desirable to have novel methods and systems forhandling and implementation of real-time communications applications andother network-performance sensitive applications in a VDI environment.

SUMMARY OF THE INVENTION

The inventive methodology is directed to methods and systems thatsubstantially obviate one or more of the above and other problemsassociated with conventional techniques for handling and implementationof real-time communications applications and other network-performancesensitive applications in a VDI environment.

In accordance with one aspect of the inventive concept, there isprovided a system for providing interactive two-way audio in a desktopvirtualization environment, the desktop virtualization environmentcomprising at least one desktop virtualization server computer and atleast one desktop virtualization client endpoint device with anassociated microphone element. The inventive system incorporates: atleast one instance of server software executing on the desktopvirtualization server and providing at least interactive user interfacefunctions to the associated desktop virtualization client endpointdevice; and at least one instance of endpoint software executing on adesktop virtualization endpoint device comprising a network port andreceiving an incoming real-time audio stream from the network port andproviding at least real-time and display functions on the desktopvirtualization client endpoint device. In the inventive system, the atleast one desktop virtualization client endpoint is configured to:accept a real-time audio input from a microphone element associated withthe desktop virtualization client endpoint; and provide outgoingreal-time compressed audio stream to the network port responsive to thereal-time audio input from the microphone element.

In accordance with another aspect of the inventive concept, there isprovided a method for providing interactive two-way audio in a desktopvirtualization environment, the desktop virtualization environmentcomprising at least one desktop virtualization server computer and atleast one desktop virtualization client endpoint device with anassociated microphone element. The inventive method involves: providing,using at least one instance of server software executing on the desktopvirtualization server at least interactive user interface functions tothe associated desktop virtualization client endpoint device andreceiving, by an at least one instance of endpoint software executing ona desktop virtualization endpoint device comprising a network port, anincoming real-time audio stream from the network port and providing atleast real-time and display functions on the desktop virtualizationclient endpoint device; accepting, using the at least one desktopvirtualization client endpoint, real-time audio input from a microphoneelement associated with the desktop virtualization client endpoint andproviding, by the at least one desktop virtualization client endpoint,an outgoing real-time compressed audio stream to the network portresponsive to the real-time audio input from the microphone element.

Additional aspects related to the invention will be set forth in part inthe description which follows, and in part will be obvious from thedescription, or may be learned by practice of the invention. Aspects ofthe invention may be realized and attained by means of the elements andcombinations of various elements and aspects particularly pointed out inthe following detailed description and the appended claims.

It is to be understood that both the foregoing and the followingdescriptions are exemplary and explanatory only and are not intended tolimit the claimed invention or application thereof in any mannerwhatsoever.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification exemplify the embodiments of the presentinvention and, together with the description, serve to explain andillustrate principles of the inventive technique. Specifically:

FIG. 1 depicts an exemplary conventional desktop computing environment.

FIG. 2 depicts an exemplary abstracted VDI decomposition of theexemplary conventional desktop computing environment of FIG. 1.

FIG. 3 a depicts an exemplary abstracted multiuser VAI computingenvironment.

FIG. 3 b depicts an exemplary abstracted multiuser VDI computingenvironment.

FIG. 3 c depicts an exemplary abstracted computing environment thatcombines VAI and VDI approaches.

FIG. 4 a depicts a first exemplary illustration of the wide range oftopological variations viable within the applicable VDI framework.

FIG. 4 b depicts various exemplary arrangements for employing and/orincorporating aspects of VDI architecture solely within a user platform.

FIGS. 5 a-5 e depict a second exemplary illustration of the wide rangeof topological variations viable within the applicable VDI framework andan exemplary event sequence among the entities to show exemplary rolesand functions.

FIG. 6 illustrates concerns of high-bandwidth uncompressed streamsflowing between virtual machine server sessions within and among serverplatforms as well as large full duty-cycle computation loads virtualmachine server sessions on server platforms when attempting to employtraditional VDI and VAI architectures with real-time interactive mediaapplications involving audio, video, high-performance graphics, etc.

FIG. 7 shows an exemplary implementation of a software application thatuses a Media Engine for incorporating audio and video communicationsfunctionality.

FIG. 8 illustrates an exemplary arrangement demonstrating the firststructural feature of the partitioned media engine (i.e., eliminatingthe need to transmit high-bandwidth media streams throughterminal-server/terminal-client network connections).

FIG. 9 shows an arrangement in accordance with another embodiment. Thisarrangement demonstrates a subset of the structural features of thepartitioned media engine.

FIG. 10 shows an arrangement in accordance with another embodimentsimilar to that described in FIG. 9.

FIG. 11 shows yet another embodiment demonstrating a subset of thestructural features.

FIG. 12 depicts an exemplary architecture of a contemporaryhigh-functionality real-time interactive collaboration application whoseimplementation comprises a media engine providing two-way audio andvideo.

FIG. 13 illustrates an exemplary class diagram showing an aggregationassociation between the RMEPCIient object and the RMEPConnection object.

FIG. 14 illustrates an exemplary class diagram showing the RMEP Clientmaintaining a list of ongoing transactions to track the status of eachsending request and receiving response, and the RMEP server keeping alist of incoming transactions.

FIG. 15 depicts an exemplary user experience presented by a GUI for athe exemplary contemporary high-functionality real-time interactivecollaboration application architecture of FIG. 12.

FIG. 16 depicts an exemplary implementation of the general arrangementdepicted in FIG. 12.

FIG. 17 shows an exemplary partition of the exemplary application ofFIGS. 15-16 which includes an exemplary partition of the media engineelements and the introduction of an exemplary virtual channel betweenthem.

FIG. 18 illustrates an alternate exemplary partition where the controlelement is arranged to execute at the server platform.

FIG. 19 depicts an exemplary architecture of partitioned media enginemodules integrated with Virtual Desktop Infrastructure and using thatVDI infrastructure in order to establish a control channel between them.

FIG. 20 depicts an alternative exemplary architecture of partitionedmedia engine modules integrated with Virtual Desktop Infrastructure.

FIG. 21 depicts another exemplary architecture of partitioned mediaengine modules integrated with Virtual Desktop Infrastructure.

FIG. 22 illustrates an alternative exemplary arrangement similar to thatof FIG. 8 but wherein server ME instances do not execute on virtualmachines but rather on a special server.

FIG. 23 illustrates another alternative exemplary arrangement similar tothat of FIG. 8 but wherein terminal ME instances execute within terminalclients (rather than parallel to them).

FIG. 24 illustrates yet another alternative exemplary arrangementcombining the server side modifications of FIG. 22 and the terminal sidemodifications of FIG. 23.

FIG. 25 is a block diagram illustrating an exemplary system architecturefor enabling multimedia conferencing in a virtual desktop infrastructureenvironment.

FIG. 26 provides an exemplary block diagram illustrating the RMEP Serverversion decision tree.

FIG. 27 provides an exemplary block diagram illustrating the RMEP Clientversion decision tree.

FIG. 28 illustrates an alternative embodiment similar to that of FIG. 8but wherein each server ME instance runs on a dedicated server ratherthan on a virtual machine in the server.

FIG. 29 depicts an exemplary logical representation of terminal accesstype handling as provided for by the invention.

FIG. 30 depicts an exemplary implementation of terminal access typehandling as provided for by the invention.

FIG. 31 depicts exemplary media engine initialization handling asprovided for by the invention.

FIG. 32 depicts an exemplary media engine auto-recovery sequence asprovided for by the invention.

FIG. 33 depicts a general exemplary arrangement delivering the solutionsprovided by the invention to CITRIX® environments.

FIG. 34 depicts a representation of an exemplary CITRIX® XenAppdeployment wherein all users in a connect to the same XenApp server.

FIG. 35 depicts an exemplary CITRIX® Best Practice using Standard vDisksto effectively disallowing write operations to the base image.

FIG. 36 depicts an exemplary XenDesktop arrangement which is structuredto avoid all the problems associated with running multiple instances ofan application running on the same machine at the same time.

FIG. 37 depicts a representation of a “Virtual Apps to Hosted Desktops”arrangement comprising a combination of XenApp and XenDesktop scenarios.

FIG. 38 depicts an exemplary MOCA startup sequence as provided for bythe invention.

FIG. 39 depicts an exemplary MOCA exit sequence as provided for by theinvention.

FIGS. 40 a-40 e depict various configurations of a common article orinstance of software as provided for by the invention.

FIGS. 41 a-41 c depict various information inputs used to configure thecommon article or instance of software as provided for by the invention.

FIG. 42 depicts an exemplary peer-partition of a common article orinstance of software that would otherwise execute unpartitioned on asingle desktop platform such as that depicted in FIG. 1;

FIG. 43 depicts an exemplary hierarchical-partition of a common articleor instance of software that would otherwise execute unpartitioned on asingle desktop platform such as that depicted in FIG. 1;

FIG. 44 depicts an exemplary mixed-partition (i.e., partiallypeer-partitioned, partially hierarchical-partitioned) of a commonarticle or instance of software that would otherwise executeunpartitioned on a single desktop platform such as that depicted in FIG.1.

FIG. 45 depicts an exemplary arrangement wherein an external webcam withinternal microphone is made available to at an endpoint device operatingas a VDI-client terminal, and wherein one instance of the inventivearticle or instance of software is installed on the endpoint device andanother instance of the same article or instance of software isinstalled on the associated server. The same software architecture isrelevant if the webcam and microphone are integrated into a computermonitor.

FIG. 46 depicts an exemplary arrangement wherein an external webcamwithout a microphone used together with a headset are made available toat an endpoint device operating as a VDI-client terminal, and whereinone instance of the inventive article or instance of software isinstalled on the endpoint device and another instance of the samearticle or instance of software is installed on the associated server.

FIG. 47 depicts an exemplary arrangement wherein a built-in webcam andmicrophone are made available to at an endpoint device operating as aVDI-client terminal, and wherein one instance of the inventive articleor instance of software is installed on the endpoint device and anotherinstance of the same article or instance of software is installed on theassociated server. Here the endpoint device may be a laptop computer (asdepicted), tablet computer, etc. comprising an internal microphone andinternal speaker as well as internal audio compression and internalaudio decompression.

FIG. 48 depicts in more detail wherein a peripheral webcam furthercomprises internal video compression. The same software architecture isrelevant if the webcam and internal video compression are integratedinto a computer monitor.

FIG. 49 depicts an exemplary variation on the situation depicted in FIG.48 wherein a webcam further comprises both an internal microphone andinternal audio compression. The same software architecture is relevantif the webcam, microphone, internal video compression, and internalaudio compression are integrated into a computer monitor.

FIG. 50 illustrates an exemplary embodiment of a computer/serverhardware platform upon and in the context which the inventive system maybe implemented.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the invention. It will be apparent, however, to oneskilled in the art that the invention can be practiced without thesespecific details. In other instances, structures and devices are shownin block diagram form in order to avoid obscuring the invention.

Reference in the specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the invention. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment.

Some portions of the detailed descriptions that follow are presented interms of algorithms and symbolic representations of operations on databits within a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers or the like.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. It should be understood thatthese terms are not intended as synonyms for each other. For example,some embodiments may be described using the term “connected” to indicatethat two or more elements are in direct physical or electrical contactwith each other. In another example, some embodiments may be describedusing the term “coupled” to indicate that two or more elements are indirect physical or electrical contact. The term “coupled,” however, mayalso mean that two or more elements are not in direct contact with eachother, but yet still co-operate or interact with each other. Theembodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the invention. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices. Review ofexemplary computer systems and similar electronic computing devices ispresented in Section 16.

The present invention also relates to an apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but is not limited to, any type ofdisk including floppy disks, optical disks, CD-ROMs, andmagnetic-optical disks, read-only memories (ROMs), random accessmemories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any typeof media suitable for storing electronic instructions, each coupled to acomputer system bus.

Finally, the algorithms and displays presented herein are not inherentlyrelated to any particular computer or other apparatus. Variousgeneral-purpose systems may be used with programs in accordance with theteachings herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the present invention is not describedwith reference to any particular programming language. It will beappreciated that a variety of programming languages may be used toimplement the teachings of the invention as described herein.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for asystem and a process for data replication in a distributed database in atelephony system through the disclosed principles herein. Thus, whileparticular embodiments and applications have been illustrated anddescribed, it is to be understood that the disclosed embodiments are notlimited to the precise construction and components disclosed herein.Various modifications, changes and variations, which will be apparent tothose skilled in the art, may be made in the arrangement, operation anddetails of the method and apparatus disclosed herein without departingfrom the spirit and scope defined in the appended claims.

The figures and the following description relate to preferredembodiments by way of illustration only. It should be noted that fromthe following discussion, alternative embodiments of the structures andmethods disclosed herein will be readily recognized as viablealternatives that may be employed without departing from the principlesof what is claimed.

Reference will now be made in detail to several embodiments, examples ofwhich are illustrated in the accompanying figures. It is noted thatwherever practicable similar or like reference numbers may be used inthe figures and may indicate similar or like functionality. The figuresdepict embodiments of the disclosed system (or method) for purposes ofillustration only. One skilled in the art will readily recognize fromthe following description that alternative embodiments of the structuresand methods illustrated herein may be employed without departing fromthe principles described herein.

1. CLASSICAL AND CONTEMPORARY DESKTOP COMPUTING ENVIRONMENTS

Although familiarity with details of computer systems and similarelectronic computing devices is assumed for the description of theinvention (Sections 1-15), for completeness review of exemplary computersystems and similar electronic computing devices is provided in Section16.

FIG. 1 illustrates an exemplary implementation of a conventional desktopcomputing.

Specifically, FIG. 1 illustrates a single operating system 102 executingon a hardware platform (not shown) associated with the specific desktopcomputing environment. Under the control and in communications with theoperating system 102, one or more applications 103 a-103 n execute alongside the operating system. Each of these one or more applications 103a-103 n interface directly with the operating system 102, making OScalls and exchanging events and data via signal lines 104, 106, 108, and110. The operating system 102 receives user interface events from thekeyboard 114, pointing devices (such as a mouse), etc. In the embodimentillustrated in FIG. 1, these devices are shown as external to theComputing Hardware Platform, but in other implementations they may alsobe integrated into the Computing Hardware Platform (for example, as inthe case of a laptop/tablet computer used as a desktop resource orsurrogate).

The operating system 102 additionally integrates or in other waysinteracts with a window system 120. The window system 120 in turnreceives user interface events from the keyboard 114, pointing devices(such as a mouse), etc., and additionally directs graphics operationcommands, via the operating system 120, to graphics rendering hardwareand software 112. In the embodiment illustrated in FIG. 1, such graphicsrendering hardware and software reside in a graphics card, but in otherimplementations they may also be integrated into the Computing HardwarePlatform (for example, as in the case of a laptop/tablet computer usedas a desktop resource or surrogate).

The aforementioned graphics operations may comprise text and graphics asused in typical applications, but may also include otherhigher-performance media types and/or high media update rates as may beneeded for the rendering of animations or video.

The operating system 102 also provides one or more audio streams toaudio rendering hardware (and in some implementations, audio software)116 for audio to be provided to the user, etc. This audio may comprisesonic indication of events as directed by the operating system, but mayalso comprise audio file playback (for example MP3 files),Voice-over-IP, rendered MIDI file playback, etc. In the exemplaryarrangement of FIG. 1, such audio rendering hardware reside in an audiocard and/or external device (such as powered speakers or headphones),but in other implementations they may also be integrated into theComputing Hardware Platform (for example, as in the case of alaptop/tablet computer used as a desktop resource or surrogate).

In many contemporary computers, the operating system 102 also receivesstreams from one or more audio and/or video capture devices 118. In theembodiment illustrated in FIG. 1, such audio and/or video capturedevices 118 are implemented as one or more external devices (such as“webcam” component and/or or headphones), but in other implementationsthey may also be integrated into the Computing Hardware Platform (forexample, as in the case of a laptop/tablet computer used as a desktopresource or surrogate).

2. OVERVIEW OF VIRTUALIZED DESKTOP COMPUTING ENVIRONMENTS

VDI arrangements of various types “divide” the conventional desktopcomputing environment into a client/server arrangement in the sense thatendpoint software and devices render visual display as instructed bysoftware applications running on one or more other computers (typicallyserver computers located at data centers), and further in which endpointsoftware and devices collect and forward input events and data fromusers and provide these to those software applications running on theone or more other “endpoint computers” (such as conventional PCs,stripped down PC, low performance PCs, specialized terminals such asthose manufactured by WYSE®/HEWLETT-PACKARD®, and various types ofhandheld devices with communications provided over carrier services).Increasingly adopted terminology includes:

-   -   Use of “remote terminal” as the term for the hardware and        internal operating system executing on the reduced functionality        “endpoint computer”;    -   Use of “terminal server” as the term for the hardware and        operating system executing on the server or other        higher-performance and/or centralized computing system; and    -   Use of “terminal client” as the term for software executing        strictly on a remote terminal.

Typically, VDI implementations transmit graphical output fromapplication programs executing at the terminal server from the terminalserver to the terminal client, and user input from the terminal clientto the terminal server. This basic architecture works well for mostdata-based office applications such as word processing, spreadsheets,database queries, standard web page browsing, etc.

In many ways, VDI in at least a high-level view, resembles the X WindowSystem architecture from the mid 1980's (and still used today as awindowing system on Linux desktops), not only architecturally (where inmany ways the X window Server acts as the remote terminal softwareenvironment) but also in regard the products and marketplace for Xterminals made by WYSE® and HP®, among others (see for examplehttp://en.wikipedia.org/wiki/X_terminal).

At a more detailed level, there is a range of implementations,variations, and ongoing evolutions in VDI realizations and productarchitectures. Rather than run through every possible detailed approach,FIG. 2 depicts an abstracted high-level overview of the decomposition ofthe exemplary conventional desktop computing environment of FIG. 1,showing at the top of the figure a conceptual instance of the software(operating system, window system, and applications) comprised by theexemplary desktop computing environment of FIG. 1, and in the bottom ofthe FIG. 2 showing a generalized split of that conceptual instanceacross a “Server” computing hardware platform and a “Terminal” computinghardware platform.

Note that it is also possible for multiple terminal clients to share thesame terminal server instances. In that case, applications and possiblydesktops from a plurality of users all share the same operating systemexecuting on the terminal server hardware. Each user's applications areaccessed from a separate instance of the terminal client, one for eachuser. We refer to this type of environment as Virtual ApplicationInfrastructure rather than Virtual Desktop Infrastructure, since remoteclients will access specific applications running on the terminal serverrather than that terminal server's entire operating environment.

The portion of software (operating system, window system, andapplications) that runs on the “Server” computing hardware platform canin principle run on any kind of computing environment. In certaincircumstances, it may run on a dedicated computer. However, in industry,this portion of software runs as one of many other instances of suchsoftware on a server computer, for example as provided by a data center.In this situation, the server runs these instances as “virtual machines”that execute on a server, each virtual machine acting as if it were(i.e. emulating) a hardware computer platform running the aforementionedsoftware. By running a plurality of virtual machines a single servercomputer, that single server computer not only may host a plurality ofactive users but further the software running on the virtual machine canbe positioned to provide a number of administrative and user advantages.The number of advantages, but general and specific to specificimplementations, is large, but a representative list includes:

-   -   Virtual desktop and application infrastructure allows        enterprises to centralize the management and delivery of        applications and desktops, thereby significantly reducing the        cost of desktop management;    -   Virtual desktops support mobility by making it easy for users to        work productively from anywhere with the best application        performance and security regardless of location. The resultant        “virtual desktops” are tied to user identities rather than        specific devices. A user may have one or more desktops which are        able to be accessed by the user as the user moves from device to        device, providing robust freedom and mobility; and    -   Thin client infrastructure provides “green IT” that is aimed at        lowering power consumption, lowering heat generation which        reduces the need for cooling, and saving energy (e.g. through        the absence of servers in the building).

FIG. 3 a depicts an exemplary abstracted multiuser VAI computingenvironment. Here, a server computing hardware platform hosts theexecution of a plurality of application sets (here N instances), each ofwhich connect over a networked environment via a VAI network Protocolwith associated “terminal client” software executing on an associatedterminal computing hardware platform serving as a remote terminal. Oneor more of the remote terminals may include audio and/or videocapabilities.

FIG. 3 b depicts an exemplary abstracted multiuser VDI computingenvironment. Here, a server computing hardware platform hosts theexecution of a plurality of instances (here, N instances) of virtualmachines, each of which connect over a networked environment via a VDInetwork Protocol with associated “terminal client” software executing onan associated terminal computing hardware platform serving as a remoteterminal. One or more of the remote terminals may include audio and/orvideo capture capabilities.

FIG. 3 c depicts an exemplary abstracted computing environment thatcombines VAI and VDI. Here, a server computing hardware platform hoststhe execution of a plurality of instances (here, M instances) of virtualmachines. Each virtual machine in turn hosts the execution of aplurality of applications sets (here N instances), each of which connectvia a VAI/VDI network Protocol with associated “terminal client”software executing on an associated terminal computing hardwareplatform. As before, one or more of the remote terminals may includeaudio and/or video capabilities.

The exemplary arrangements of FIGS. 3 a-3 c, however, are to be furtherviewed in an even more widely abstractable way as there are manypossible variations of, on, and within the exemplary depictedtopological examples. For example, FIG. 4 a illustrates topologicalvariations viable within the applicable VDI framework in accordance withone embodiment. In one embodiment, a plurality of servers d02 a/d02 n isavailable for executing one or more instances of virtual machines d04 a,d04 b, d04 c, d04 e. The data files defining virtual machines resides onthe server it executes on or, as described shortly, is recalled from adatabase associated with that server, or is allocated to a one oranother among a plurality of servers in response to on-demand logins orother forms of authorized or trusted requests. In an alternateembodiment, a virtual machine executes on a user platform, such as adesktop PC, laptop PC, etc., which is also able to run otherapplications. As shown in FIG. 4 a, a plurality of virtual machines areexecuted on hardware platforms. In some implementations the hardwareplatforms can also run other applications.

In one embodiment, a single terminal client software instance runs on auser platform, which runs only the terminal client. In anotherembodiment, a single terminal client software instance runs on a userplatform, which runs one or more other applications in addition to theterminal client. In a third embodiment, two or more terminal clientsoftware instances run on a user platform, which runs otherapplications. In yet another embodiment, one or more terminal clientsoftware instances run on a user platform, which runs an instance of avirtual machine, and which additionally (although this variation notshown) also executes one or more other applications.

As an additional group of illustrative examples, FIG. 4 b depictsvarious embodiments for employing and/or incorporating aspects of VDIarchitecture within a common user platform. The advantages of this caninclude using the same software entities in either stand-alone computersor networked VDI environments. In a first embodiment, an associatedvirtual machine 454 and terminal client 456 reside and execute solelywithin a common user platform 452. In a second embodiment, an associatedvirtual machine 460 and terminal client 462 reside and execute alongwith other applications 464 within a common user platform 452. In athird embodiment, a plurality of associated virtual machine 470 a-470 nand terminal client “pairs” 472/474 commonly resided and sequentiallyand/or concurrently execute within a common user platform 468, whichadditionally also executes one or more other applications 464.Additional aspects of such arrangements are discussed below.

As further group of illustrative examples, FIGS. 5 a-5 e provide both(a) a third exemplary illustration of the wide range of topologicalvariations viable within the applicable VDI framework and (b) anexemplary event sequence among the entities to show exemplary roles andfunctions. Many variations of this are possible as is apparent to oneskilled in the art.

In the exemplary arrangement of FIG. 5 a, a user or automated processrunning on a terminal computer or equivalent may use a VDI login utilityto contact a provisioning server 502 with a provisioning request. Theprovisioning server 502 seeks a user record 504 to authenticate the useror automated process and identify how and/or where to find a copy of thesoftware used to implement an instance of the particular virtual machineand terminal client associated with the provisioning request. In oneembodiment, the user record 504 resides in some type of user recorddatabase 506. In another embodiment, the user record 504 is part of theprovisioning server 502 (not depicted). In yet another embodiment, theuser record 504 is provided by some other arrangement (not depicted).Further, as shown in embodiment illustrated in FIG. 5 a, the user recorddatabase 506 may be centralized (as depicted) In another embodiment, theuser record database 506 is a decentralized database with full orpartial replication. The latter arrangement can advantageously allow forindividual database instances to act as a cloud server for servicinglarge fluxes of provisioning requests and/or widely geographicallydispersed implementations of the VDI environment.

In the embodiment shown in FIG. 5 b, the information regarding howand/or where to find a copy of the software used to implement aninstance of the particular virtual machine and terminal clientassociated with the provisioning request 502 is retrieved and used toretrieve a “user image” 508 comprising, for example, particular virtualmachine and terminal client associated with the user in turn associatedwith the provisioning request. In one embodiment, the user image 508resides in some type of user image database 510 (as depicted). Inanother embodiment, the user image 508 is part of the provisioningserver 502 (not depicted). In yet another embodiment, the user image 508is provided by some other arrangement (not depicted). Further, as shownin embodiment illustrated in FIG. 5 b, the user image database 510 maybe centralized (as depicted). In another embodiment, the user imagedatabase is a decentralized database with full or partial replication.The latter arrangement can advantageously allow for individual databaseinstances to act as a cloud server for servicing large fluxes ofprovisioning requests and/or widely geographically dispersedimplementations of the VDI environment.

In another embodiment (not depicted) of the arrangements of FIGS. 5 aand 5 b, the user record and user image resides in the same database. Inyet another embodiment (not depicted) of the arrangements of FIGS. 5 aand 5 b, the user record and user image is the same file or group ofassociated files. In yet another embodiment (not depicted) of thearrangements of FIGS. 5 a and 5 b, the user record and user imageresides on the provisioning server. Other exemplary embodimentsregarding aggregations of these functions with other functions aredescribed in more detail below.

In the embodiment as illustrated in FIG. 5 c, the successful location ofuser image 508 results in notification of this event (or failure) to theprovisioning server 502. In one embodiment, the provisioning server 502then allocates a particular session server 512A from one or moreavailable session servers 512A, 512B. The session server 512A, if theallocation is successful, will subsequently execute an instance of thevirtual machine associated with the user record 504. In one embodiment,the system hosting the located user image 508 allocates a particularsession server 512A from one or more available session servers512A/512B. In some embodiments where there are more than one sessionservers 512A/512B, allocations are made according to various loadbalance, geographic, logical partitioning, hashing, or other allocationschemes. In another embodiment, the plurality of session servers512A/512B depicted in FIG. 5 c are collectively coordinated in acloud-computing or other equivalent arrangement so as to act as a singleserver.

In yet another embodiment (not depicted) of the arrangements of FIGS. 5a, 5 b and 5 c, the user record 504 and user image 508 resides on acombined server that provides the functionality of the aforementionedprovisioning server 502 and the session server 512A.

As shown in an embodiment illustrated in FIG. 5 d, the located userimage 508 is retrieved and used to (1) send a server file to the sessionserver 512A to be executed as a server session 514 on the allocatedsession server 512A and act as a virtual machine, and (2) send aterminal file to the terminal computer 516 or equivalent to be executedas a terminal session 518 on the terminal computer 516 or equivalent andact as a terminal client. In one embodiment, the terminal file resideson the terminal computer 516 or equivalent. In another embodiment, theterminal session and login utility 520 are the same program or group ofprograms. In yet another embodiment, the terminal file is sent to theterminal computer 516 or equivalent by the session server 512A,particularly if the session server 512A is integrated with the userimage database 510 and/or provisioning server 502 as in some of theaforementioned embodiments.

As shown in an embodiment illustrated in FIG. 5 e, the terminal session518 (executing on the terminal computer 516 or equivalent and acting asa terminal client) and server session 512A (executing on the allocatedsession server and acting as the corresponding virtual machine)communicate with a VDI network protocol and collective emulate and/orimplement the user computer environment as if it were a traditionalunitary computer arrangement like that of FIG. 1.

It is understood that there are a wide range of possible variations onthe embodiments provided above as is clear to one skilled in the art.Further, VDI technology is rapidly evolving and differentiating sofurther variations and improvements are expected. These are provided forby the invention to be described. Prior to description of the invention,however, problems with the performance and scalable support of real-timemedia—including interactive real-time audio, video, animation,instrumentation, visualization, and/or other media types are describedin the next section.

3. PROBLEMS OF SUPPORTING REAL-TIME INTERACTIVE MEDIA IN THE ESTABLISHEDVDI ARCHITECTURE

In the traditional VDI architectural framework, terminal serverstransmit graphical output of programs from to the terminal client, anduser input captured at the terminal client is sent from to the terminalclient to the terminal server. There can be significant scaling andperformance problems when using the aforementioned VDI architecturalframework to support real-time media such as audio, video, animations,high-performance graphics, etc. The VDI architectural framework wouldforce the transmission of real-time media streams for the audio,animations, high-performance graphics, video, etc. over the networkenvironment first between each paired terminal client and terminalserver (and in the case of two-way collaboration applications,additionally between the terminal server session instances for the usersinvolved). Of key concern is that the VDI model of hosting the portionof applications creating raw graphics, image, and audio at the serverresults in the streams between the terminal client and terminal serverto be raw uncompressed data. Even if a wideband connection and networkadapters could handle the resultant massive flow of such an exchange forone terminal client/terminal server pair, more than a few active usersof the this type would choke the network carrying capacity and/or serverI/O capacity. These concerns are illustrated in FIG. 6. For media typessuch as video, animations, high-performance graphics, and the like, theresult would be poor quality from erratic updating and often highlatency. Similarly, real-time audio would suffer from dropouts and oftenhigh latency. The result is completely impractical with regards toscalability and thus flies directly against the principle goal of VDItechnology.

Some VDI product manufacturers have addressed the fraction of theseconcerns relaying to 1-way streaming media applications (wherebulk-delay is not an issue) by implementing Flash Players and other suchmedia-file player utilities locally at the terminal hardware platform.However, such approaches do not address interactive applicationsinvolving real-time media. This has remained an important and growingproblem as applications increasing employ interactive real-time mediasuch as audio, animations, high-performance graphics, video, and thelike.

In summary, key remaining problems include:

-   -   Protocols used by VDI and VAI are typically based on TCP.        However, delivery of real-time audio, video, high performance        graphics, etc. over TCP is not practical due to the inherent TCP        methods of handling of packet loss;    -   Performing audio/video compression and decompression at the        server consumes extensive computation power with a full        duty-cycle and forces uncompressed streams through the network        ports; these impose significant limits to practical scalability        of VDI and VAI servers in actual VDI and VAI deployments;    -   Server-based audio/video compression requires excessive network        bandwidth to allow uncompressed audio/video to be sent over the        network. For example, a simple uncompressed video CIF stream        running at 30 fps uses approximately 50 Mb/s. This imposes        significant limits to practical network-loading scalability of        VDI and VAI deployments and in reality makes video over VDI        impractical at best in local area deployments and essentially        impossible in wide-area deployments.

4. APPROACHES TO ADAPTING REAL-TIME MEDIA ENGINES (FOR AUDIO, VIDEO,ANIMATION, INSTRUMENTATION, VISUALIZATION AND/OR OTHER MEDIA TYPES) TOVDI ARCHITECTURE

Although some implementations of applications including interactivereal-time media such as audio, animations, high-performance graphics,video, and the like are implemented without regard to special executionand networking performance requirements, it has become relatively commonin modern software engineering practices for real-time media encodersand decoders (usually together with related stream handling and control)to be implemented in the form of self-contained modules that encapsulateaudio/video processing, call management, and related functionality andexpose well-defined abstract interfaces to the functionality theyimplement. These modules are typically bundled together into a completesoftware package that can be used by application software developers toincorporate audio/video functionality into their systems without havingto concern themselves with the details of managing audio and videocommunications. For the purposes of illustration, such a packagingarrangement will be assumed and this package will be called a “mediaengine” and will in places be abbreviated as “ME” in diagrams. FIG. 7shows an exemplary implementation of a software application that uses aMedia Engine for incorporating audio and video communicationsfunctionality. In the diagram, the software application runs on atraditional PC or laptop 702. The application comprises a graphical userinterface 704 that provides user with access to the application logicmodule 706. The application module 706 in turn provides voice and videocommunications functionality by accessing a media engine 708 through themedia engine interface 710.

The problems identified in the preceding section can be readilyaddressed by an appropriately partitioned media engine implementation.The resultant partitioned media engine implementation also provides anumber of architectural flexibilities making it very useful in a varietyof settings.

The first structural feature of the partitioned media engine is toeliminate the need to transmit high-bandwidth media streams throughterminal-server/terminal-client network connection(s). This isaccomplished by partitioning the media engine so that media processing,including capture, encoding, sending, receiving, decoding, and playback,is performing on the terminal client.

A second structural feature, in accordance with one embodiment, is toavoid sending any media streams across the VDI protocol (throughterminal-server/terminal-client network connection(s), which then allowsvoice and video traffic to take advantage of network support (e.g. QoS,packet prioritization, bandwidth management) designed to optimize thedelivery of voice and video. This is accomplished by partitioning themedia engine so that media transmission, including sending, receiving,jitter compensation, packet loss concealment, is performing on theterminal client.

A third structural feature, in accordance with one embodiment, is tooffload CPU intensive media compression and decompression functions fromthe terminal server. This is accomplished by partitioning the mediaengine so that media encoding and decoding is performing on the terminalclient.

A fourth structural feature, in accordance with one embodiment, is toshield the client application as much as possible from the complexitieswithin VDI implementations.

A fifth desirable structural feature, in accordance with one embodiment,is to shield the system administrator from instillation and maintenancecomplexities when implementing the partitioned media engine in areal-world VDI environment.

FIG. 8 illustrates an arrangement demonstrating the first structuralfeature of the partitioned media engine in accordance with oneembodiment (i.e., eliminating the need to transmit high-bandwidth mediastreams through terminal-server/terminal-client network connections). Inthis arrangement, each VDI session wherein one or more applicationsemploying interactive audio, animations, high-performance graphics,video, and the like are invoked causes:

-   -   a server ME 802 a-802 n portion of a media engine to execute        within the virtual machine server session; and    -   a corresponding terminal ME 804 a-804 d portion of a media        engine executing on the corresponding terminal platform 806        a-806 e.

In such an exemplary arrangement, full duty-cycle computationsadvantageously employed or required for media encoding and/or decoding(and related stream handling and control) run within the terminal ME 804a-804 d executing at the terminal platform 806 a-806 e and compressedmedia streams are sent directly between the terminal ME and the otherparty in a call. This prevents:

(1) transmission of uncompressed real-time media though the VDIinfrastructure, server, network ports, and general network environment,and

(2) virtual machines hosted at the server having to execute fullduty-cycle computations for media encoding, decoding, stream handling,etc.

Further, in such an arrangement, all usual (non-real-time) applicationmatters such as general program execution, GUI interactions, windowhierarchy, display hierarchy, window resizing, etc., together withnaturally VDI-inherited data-oriented operations such as directories,presence, interactions with utilities such as OCS, etc., are naturallyhandled by the server ME executing in the corresponding virtual machineexecuting as a server session on a VDI server.

The fine result of this approach is that high performance is delivered,no loading is provided on servers, and only compressed streams arecarried by the network. The only requirement is that terminal platformshave the ability to successfully operate the terminal ME 804 a-804 d inaddition to the terminal client 808 a-808 e.

FIG. 9 shows an arrangement in accordance with another embodiment. Thisarrangement demonstrates a subset of the structural features of thepartitioned media engine. In this embodiment, transmission ofhigh-bandwidth media streams is avoided by performing audio and videocompression on the terminal client 908 a/908 b rather than on theterminal server. However, compressed media streams are transmittedthrough the VDI connection (i.e., terminal-server/terminal-clientnetwork connection), that is “in-band” in the VDI connection, andconnected to their associated call endpoint by the server ME 912 a/912 bvia the media stream signal path 914. (It is noted that although FIG. 9shows the associated call endpoint to be a similar server/terminal pair,in other settings, applications, or call examples the associated callendpoint could alternatively be a computer running an interactiveaudio/video application, a terminal implementing the same architectureas discussed later on (FIG. 28) in Section 12, etc.)

In an arrangement such as that of FIG. 9, server ME 904 a/904 binstances can optionally, or as advantageous, transcode media streamsinto different formats to provide for a different set of capabilitiesthan those provided by the terminal ME 904 a/904 b.

FIG. 10 shows an arrangement in accordance with another embodimentsimilar to that described in FIG. 9. In this embodiment, compressedmedia streams are relayed by the terminal ME 1004 a/1004 b, but ratherthan transmitting media through the terminal-server/terminal-clientnetwork connection as described in FIG. 9, compressed media streams aresent between the terminal ME 1004 a/1004 b and the server ME 1012 a/1012b using a communications path other than and external (i.e.,“out-of-band”) to the VDI connection (i.e.,terminal-server/terminal-client network connection) between the terminaland its associated server.

In the exemplary arrangements of FIG. 9 and FIG. 10, as well asvariations and combinations of them, the invention provides for mediastreams traveling between servers to employ non-VDI mechanisms for audioand video (e.g. encapsulating audio/video streams inside UDP/RTP packetsor other approaches). This is in keeping with classical VDI architectureas in VDI environments there is usually no server-to-server VDI channel.

The invention provides for variation and combinations of thearrangements described. For example, the invention coversimplementations wherein media streams and VDI channels are carried via acombination of TCP and UDP channels.

FIG. 11 shows yet another embodiment demonstrating a subset of thestructural features. In this embodiment, media capture, encoding, andtransmission is done by the terminal ME 1104 a/1104 b, but mediareceiving, decoding, and rendering continues to be performed by theserver ME 1112 a/1112 b.

In an embodiment, the terminal ME itself may rely on yet furthercomputational offloading, for example via an audio card, echo cancellingmicrophones, the video compression capabilities within a webcam, videodecoding hardware support embedded in CPUs or GPUs, etc.

It is additionally noted that the principles displayed here for atwo-component partition of a media engine can be used to devisepartitions with three or more components. These will be called“multi-component partitions” and will be considered later, although itis noted that the three or more resulting components may haveorganizations that may be organized in peer, hierarchical, or mixedarrangements as will be discussed.

5. APPROACHES TO TWO-COMPONENT PARTITIONED MEDIA ENGINE SOFTWAREIMPLEMENTATION

FIG. 12 depicts the architecture of a contemporary high-functionalityreal-time interactive collaboration application in accordance with oneembodiment. The interactive collaboration application includes a mediaengine 1202 providing two-way audio and video functionality. Otherembodiments with alternate, fewer, or additional features, structures,and functionalities are of course possible. For example:

-   -   In one embodiment, an interactive remote-medicine application        adds to or replaces video and/or audio streams with real-time        medical telemetry, real-time medical imaging (such as live        sonogram feeds), etc. of similar bandwidths and performance        constraints;    -   In another embodiment, incoming interactive graphics mixed with        video and outgoing live video are combined in virtual-reality        environments, which may be used in professional training,        hazardous robotics control, online interactive multi-user games,        GIS systems, social networking page mash-ups, etc.

However, the exemplary high-functionality real-time interactivecollaboration application architecture depicted in FIG. 12 can be usedto illustrate approaches to software implementation a two-componentpartitioned media engine.

In further detail, the exemplary application architecture depicted inFIG. 12 employs a GUI component connecting to a media engine componentthough the set of Application Programming Interfaces (APIs) exposed bythe Media Engine. In an embodiment, various technologies can be used toimplement these APIs. For example, Media Engine implementations can bepackaged as dynamically linked libraries (DLLs) and expose theirinterfaces using native function calls in programming languages such asC or C++, Java, or C#. Other implementations may take advantage offrameworks such as COM (Component Object Model), ActiveX, or HTTP/RESTthat are provided by the underlying operating system and provide aprogramming-language neutral way of implementing object interfaces. Manyof the examples used in this document show COM interfaces, but theexamples apply equally well to other interface technologies.

In an embodiment, a layered implementation may be used to shield theMedia Engine objects from the specific interface technology being used.For example, the lowest layer Media Engine implementation may contain aC++ object called Endpoint that provides a high-level interface tovarious aspects of Media Engine functionality. This interface mayinclude a Call( ) method that allows Media Engine clients to initiateaudio/video calls. In response to a successful call attempt, MediaEngine creates a Call object that provides an interface that allowsMedia Engine clients to manage the various aspects of the resultingcall. After the call has been terminated, information about call detailsand call statistics may be available through the interface provided by aCallLog object.

When using COM, Media Engine clients use a COM interface layer to accessMedia Engine objects. For example, Media Engine may include an IEndpointCOM interface that provides access to Endpoint functionality. Similarly,Media Engine may contain an ICall COM interface to provide access toCall functionality and an ICallLog interface for call statistics.

The Media Engine implementation may contain a Proxy layer that sitsbetween COM and the low-level Media Engine objects and that translatesCOM interfaces to low-level C++ interfaces. This proxy layer may includean EndpointComProxy object that implements the COM functionality andtranslates COM calls into the corresponding C++ calls on the Endpointobject. In addition, the Proxy layer may include a CallComProxy objectthat translates ICall COM calls to low-level Call object interfaces andICallLogComProxy object that translates ICallLog COM calls to low-levelCallLog object interfaces.

As an example, FIGS. 13 and 14 depict an exemplary class embodiment.FIG. 13 illustrates an exemplary class diagram showing an aggregationassociation between the RMEPCIient object and the RMEPConnection object.FIG. 14 illustrates an exemplary class diagram showing the RMEP Clientmaintaining a list of ongoing transactions to track the status of eachsending request and receiving response, and the RMEP server keeping alist of incoming transactions. It is clear to one skilled in the artthat such class definitions and organization may be implemented in awide manner of ways other than that described here, and such alternateembodiments of the classes are anticipated and provided for by theinvention. It is noted that the exemplary embodiments depicted in FIGS.13 and 14 will be considered later on in Sections 10-11.

The GUI component comprises not only control module h06 but alsointertwined other functions. For example, in the context of acontemporary high-functionality real-time interactive collaborationapplication, in accordance with some embodiments, the user experienceincludes aspects and information exchanges with collaborationenvironments such as LOTUS SAMETIME® and/or MICROSOFT® OCS as well asother software utilities. In the context of a contemporaryhigh-functionality real-time interactive collaboration application, theresultant user experience as presented by such a GUI component shows thegreat utility and sophistication suggested in FIG. 15. In other types ofapplications of other embodiments, LOTUS SAMETIME® and/or MICROSOFT® OCSis replaced by database display utilities, controls, and/or other GUIfeatures. Again, the application architecture depicted in FIG. 12 andassociated user experience represented by FIG. 15 are not limiting butrather serve as a representative and sufficiently rich example that canreally be scaled-up, scaled-down, and/or altered for a wide range ofreal-time-interactive two-way applications. As an exemplary arrangementfor further discussion, FIG. 16 depicts an exemplary implementation ofthe general arrangement depicted in FIG. 12.

Further as to the exemplary application architecture depicted in FIG.12, the media engine component may employ an exemplary internalstructure comprising devices element, a media element, control element,administration element and contacts element.

-   -   The Devices element 1201 provides interfaces to manage and        manipulate the audio/video devices used for interactive        communications. A typical Devices module can provide        functionality to select which devices are used to capture and        render audio and video, to change audio gain on speakers and        microphones, to set video parameters such as brightness,        contrast, saturation, etc. and to manipulate pan/tilt/zoom        controls on cameras.    -   The Media element 1202 is responsible for capturing, encoding,        sending, receiving, decoding, and rendering media. A typical        Media module manages audio streams, video streams, or both. In        some cases, multiple audio and/or video streams are used (e.g.        for stereo audio, 3D video, presentation video as well as live        video, etc.). Media modules can implement several encoders for        audio and video. For example, audio support may include one or        more of G.711, G.722, G.722.1, and AAC-LC for audio calls from 3        kHz to 14 kHz (ultra-wideband). Video support may include one or        more of H.264, H.263+, and H.263 for video with rates ranging        from 128 kb/s to 2048 kb/s. Video may be encoded at up to 30 fps        (depending on the webcam used). In most cases, media are        encapsulated using RTP and sent over UDP, although other        transmission media can be used as well.    -   The Control element 1203 is responsible for call setup and        teardown, call management (providing features such as call hold,        resume, and transfer), and conference management. This module        can also include registration support to interact with call        processing servers, and can implement support for NAT and        firewall traversal. Control modules typically implement        industry-standards protocols such as SIP and H.323 for basic        call signaling and call processing functionality, as well as        special-purpose protocols such as STUN, TURN, and ICE for        firewall traversal.    -   The Admin element 1204 provides administrative functionality        such as configuration of system settings, user preferences, and        administrator policies, storage and retrieval of call detailed        records (CDRs), managing and enforcing software licensing        restrictions, and logging of all system activity including debug        logs, performance histories, etc.    -   The Contacts element 1205 manages user credentials and logins,        stores address book information, interacts with corporate        directories and presence systems. In this exemplary arrangement,        the contacts element may also link to outside utilities,        parameter sets, etc.

Again, the application architecture depicted in FIG. 16 is not limitingbut rather serve as a representative and sufficiently rich example thatcan really be scaled-up, scaled-down, and/or altered for a wide range ofreal-time-interactive two-way applications.

FIG. 17 shows an exemplary partition of the exemplary application ofFIGS. 15-16 which includes an exemplary partition of the media engineelements and the introduction of an exemplary control channel betweenthem. In this embodiment, the contact and administration elements of themedia engine are coupled to the GUI component and the application logic,executing on a virtual machine or other server session on a serverplatform, all in full keeping with traditional VDI technology. Whatdeviates from traditional VDI technology is:

-   -   The high-bandwidth, high CPU usage (media, devices, and control)        elements of the media engine do not run on the virtual machine        in a server session on a VDI server platform. Instead, a        completely separate software program of set of software programs        executes separately on the terminal platform; and    -   The portion of the media engine executing on the server platform        and portion of the media engine executing on the terminal        platform are each supplemented with a respective virtual channel        driver, and these two respective virtual channel drivers        establish an active virtual channel between the two portions of        the media engine.

In this embodiment, the following parts of Media Engine functionalityrun on the terminal client:

-   -   The entire media processing chain, including device selection,        capture, playback, encoding and decoding, and RTP network I/O;    -   Functions and operations for video window overlay and/or        clipping;    -   Signaling protocol SIP, H.323, etc. endpoint software (including        registration functions); and    -   Additional networking code in support of signaling protocols        (SIP, H.323, etc.), transport protocols (for example, RTP), etc.

The rest of Media Engine functionality runs on the terminal server. Thisincludes:

-   -   Licensing;    -   Persistent configuration storage;    -   Debug logging;    -   Call history logging; and    -   Address Book functionality.

FIG. 18 illustrates an alternate exemplary partition where the controlelement is arranged to execute at the server platform. The decisionwhether to execute the control element (containing call signaling, calland conference management, and networking code) on the terminal clientor on the terminal server is affected by the amount of interactionbetween the control and media elements. For example, in an embodiment,firewall traversal functionality can be provided by a self-containedmodule that acts as a SIP and RTP proxy capable of firewall traversal onthe outward-facing side. In this embodiment, interactions between themedia element and the control element can be minimized by keeping theseelements local on the same terminal client since they share the samefirewall traversal module.

If firewall traversal functionality in Media Engine is provided throughmechanisms that do not include a separate SIP/RTP proxy module, othermedia engine partitioning may be possible or preferred.

It is explicitly noted the exemplary partitions above are only twoexamples, and a wide range of alternate partitions are possible.

Further, it is explicitly noted that although the exemplary partitionsabove are provided in terms of audio/video collaboration, the samegeneral principles apply to a wide range of alternate applications andmedia types including high-performance graphics, telemetry display, etc.

6. APPROACHES FOR PROVIDING INTERFACES TO TWO-COMPONENT PARTITIONEDMEDIA ENGINES

Media Engines provide Application Programming Interfaces (APIs) toexpose their functionality and to enable interaction between the GUIportion of application software and the Media Engine component. In anembodiment, the API implemented by the media engine will provide asimple and comprehensive object-oriented audio/video software endpoint.Support for remote terminals will be based on extending this objectmodel across the network between the terminal server and the terminalclient to support interaction between the Terminal Media Engine and theGUI portion of the application. Various such interactions are useful ormay be advantageous. For example:

-   -   Audio input and output volume adjustment, tone control,        equalization control, and/or other similar information known to        the GUI portion of the application can be passed to the TE for        proper control of audio capabilities;    -   Compression and decompression setting information known to the        GUI portion of the application can be passed to the TE for        proper control of compression and decompression functions;    -   A/V device attachment/detachment events,    -   A/V device plug and play events,    -   A/V device properties and settings etc., and/or    -   Error conditions for A/V devices, compression and decompression        software, incoming media streams, etc., can be passed from the        TE to the GUI portion of the application for display to the        user.

In an embodiment, the classes and interfaces exposed by the media enginewill be separated into “local” and “remote” based on where thecorresponding code will executed in the remote terminal scenario. In theexample embodiment considered earlier, described later on in Sections10-11, and depicted in FIGS. 13 and 14, “remote” interfaces, coveringterminal client functionality as defined above, will include IEndpoint,ICall and any interfaces accessible through it, but not ICallLog.

Some arrangements may define a well-defined set of interfaces to beRemote. Other arrangements may define interfaces to be “Remotable” byproviding for a selectably optional incorporation or implementation of aremote interface. In an embodiment, the remote interface option may beselected by one or more of:

-   -   automatically selected under software control at installation or        at runtime;    -   selected by administrator personnel at installation;    -   selected by administrator personnel at other times;    -   selectable by a user at other times and/or under other        conditions; and/or    -   automatically selected by software control at other times and/or        under other conditions.

The “remotable” approach allows for the same Media Engine software to beused in VDI as well as non-VDI environments.

The instance of the media engine used by the client application on theterminal server will implement the “local” interfaces in the normalmanner (e.g., the address book interfaces will continue to work with thelocal address book storage). For “remote” interfaces, the implementationof the interface must rely on a control channel to the Terminal MediaEngine and translate commands across the Media Engine Interface intomessages sent across the control channel. Similarly, messages receivedfrom the control channel must be translated into replies or eventscommunicated to the application using the Media Engine Interface. Wewill refer to the network protocol used to carry these messages as theRemote Media Engine Protocol (RMEP).

In an embodiment, the first media engine instance will implement proxycode that will forward API requests to, and receive responses andnotifications from, the second instance of Media Engine running on theterminal client. The second media engine instance will use the current,concrete implementations of the “remote” interfaces. It will not need toprovide any functionality for “local” interfaces, and in fact, access tosuch interfaces will be disabled.

In an embodiment, remote interfaces may be provided by Remote COM Proxyclasses in the COM Proxy layer that provide alternative implementationsof existing COM interfaces (see FIG. 16). For example, with remoteterminal support in place, there will be two distinct implementations ofthe ICallComProxy object in media engine: the pre-existingimplementation using the C++ EndpointCall class, and a newimplementation forwarding COM calls to a remote media engine instanceusing RMEP. Depending on the low-level design, these classes may berealized either as independent implementations of ICall, or derived froma common abstract ancestor class.

In addition to providing support for remote interfaces, a Remote MediaEngine Protocol can also be used to provide various behind-the-scenescoordinations between the Terminal Media Engine and the GUI portion orServer Media Engine portions of the application. The followingcoordinations may be useful or advantageous:

§ Window location, window size, window relocating, window resizing,window coverage hierarchies and window coverage geometry informationknown to the GUI portion of the application can be passed to the TE forproper rendering of the video window;

In an embodiment, a separate Window Monitoring Module may be added tothe Server Media Engine to track video window position, size, andvisibility and propagate this information using a RMEP protocol to aWindow Positioning Module that is part of the Terminal Media Engine. TheWindows Positioning Module ensures that video is rendered in the correctlocation on the remote terminal as determined by the Application GUIrunning on the terminal server.

7. APPROACHES TO ESTABLISHING CONTROL CHANNELS BETWEEN PARTITIONED MEDIAENGINE MODULES

FIG. 19 depicts an exemplary architecture of partitioned media enginemodules integrated with Virtual Desktop Infrastructure and using thatVDI infrastructure in order to establish a control channel between them.In the discussion to follow, the term “Virtual Channel” always implies“carried over the VDI connection;” further, in the context of FIG. 19,it is implied that control data are sent across a Virtual Channel overthe VDI connection. Note that FIG. 19 does not depict media channels,only control channels. With these points established, the exemplaryarchitecture depicted in FIG. 19 has the following elements andcharacteristics:

-   -   An audio/video software application 1901 runs on a terminal        server 1902. The software application uses VDI server software        5100 to communicate with a VDI client 1909 running on a terminal        1907.    -   The software application consists of application logic 1903 that        accesses a server media engine 1904 using the media engine's        interface 1905 (e.g. a COM interface). In this case the local        portion of the interface 1905 will be used to access the server        media engine 1904.    -   The software application 1903 uses the same interface 1905 to        access a terminal media engine 1906 running on a terminal 1907.        In this case, the remote portion of the interface 1905 will be        used to access the terminal media engine 1906.    -   The terminal media engine 1906 is deployed using a plug-in 1908        into the VDI client 1909 running on the terminal 1907. The plug        in 1908 accesses the terminal media engine 1906 using the media        engine's interface 1910 (e.g. a COM interface). In this case,        the remote portion of the interface 1910 is used.    -   The control channel between the terminal media engine and the        server media engine uses a Virtual Channel 1911 through the VDI        connection 1912 between the VDI client 1909 and the VDI server.        Calls across the remote portion of the server media engine        interface 1905 are translated by a proxy module 1913 into        protocol messages that are transmitted across the Virtual        Channel 1911 using a Virtual Channel driver 1914.    -   On the terminal 1907, protocol messages are received from the        virtual channel 1911 by a virtual channel driver 1915 and        translated back into calls across the remote portion of the        terminal media interface 1910. These calls are then executed by        the terminal media engine 1906.    -   Conversely, events and/or errors generated by the terminal media        engine 1906 are sent across the interface 1910 to the VC driver        1915. This drives translates these events into protocol messages        to be sent across the Virtual Channel 1911 and received by the        Virtual Channel driver 1914, where they are sent to the proxy        module 1913 that translates these protocol messages back into        events and/or errors to be sent to the application 1903 across        the interface 1905.

FIG. 20 depicts an alternative exemplary architecture of partitionedmedia engine modules integrated with Virtual Desktop Infrastructure.This exemplary architecture is very similar to the architecture depictedin FIG. 19 with the following difference: rather than using a VirtualChannel across the VDI connection for establishing a control channel,the Proxy module on the terminal server uses a direct connection (e.g.using TCP) to the VDI client plug-in on the terminal. This architectureis advantageous for VDI technologies that do not have support forvirtual channels.

FIG. 21 depicts yet another exemplary architecture of partitioned mediaengine modules integrated with Virtual Desktop Infrastructure. Thisexemplary architecture is very similar to the architecture in FIG. 20with the following difference: rather than deploying the terminal mediaengine as a plug-in to the VDI client it is deployed as a separatemodule that runs side-by-side with the VDI client rather than as aplug-in. This architecture is advantageous for VDI technologies that donot support a plug-in architecture for the VDI client. Moreover, thisarchitecture provides separation between the media engine and the VDIclient such that the VDI client is protected from any failure of theMedia Engine and the Media Engine is protected from any failures of theVDI client.

FIG. 22 illustrates an alternative exemplary arrangement similar to thatof FIG. 8 but wherein server ME instances do not execute on virtualmachines but rather on a special server.

FIG. 23 illustrates another alternative exemplary arrangement similar tothat of FIG. 8 but wherein terminal ME instances execute within terminalclients (rather than parallel to them).

FIG. 24 illustrates yet another alternative exemplary arrangementcombining the server side modifications of FIG. 22 and the terminal sidemodifications of FIG. 23.

FIG. 25 shows another exemplary architecture that combines elements fromthe previous architectures. In this architecture, the Media Engine isdeployed as a separate module that runs side-by-side with the VDI clientrather than as a plug-in. Rather than using a direct connection betweenthe proxy module and the terminal media engine, a Virtual Channel isestablished through the VDI connection. This architecture providesseparation of the media engine and the VDI client such that the VDIclient is protected from any failures of the Media Engine and the MediaEngine is protected from any failures of the VDI client. However, thisarchitecture leverages the existing connection between the VDI clientand the VDI server, thereby avoiding potential connectivity problems(e.g. introduced by firewalls or routing policies) between non-VDIsoftware modules running on the terminal and the server.

In an embodiment, the remote channel between partitioned media enginemodules may comprise the following software modules:

-   -   A Remote Media Engine Protocol implementation library    -   A Remote COM Proxy module, implemented as a class library inside        Media Engine, will implement the interface proxy functionality        for “remote” interfaces, translating between COM method calls        and notifications, and RMEP messages, and satisfying property        requests out of the local property cache.    -   A Terminal Server Connector module, also implemented as one or        several class libraries inside Media Engine, will use the APIs        provided by remote terminal server software to detect remote        terminal sessions, establish connectivity with the code running        on the terminal client, and provide the server-side part of the        communication channel for RMEP messaging.    -   A Terminal Client Connector module may be implemented as        separate binaries (DLL), or linked into the Media Engine Host        executable (see below). The responsibility of this code would be        to provide a link with the terminal client application, receive        and process connection requests, activate the Media Engine Host        process, and provide the terminal-side part of the RMEP        communication channel.    -   A Media Engine Host executable (EXE) will provide an isolated        process environment for running the client-side Media Engine        instance. It will translate RMEP messages into COM calls, and        also allow Media Engine to run in a more controlled environment        outside and independently of the terminal client process, set        process priority, load and unload additional DLLs, etc.

Other variations are possible and are provided for by the invention.

Regarding such exchanges between the GUI portion of the application andthe TE, many implementations are possible and some of these are affectedby the deployment details and/or provisioning outcomes:

-   -   The exemplary partition above with the SE running on the virtual        machine will operate on any of the configurations depicted in        FIGS. 8 and 23, as well as variations on these and combinations,        and these configurations will operate in any one or more of the        configurations depicted in FIGS. 2-3, 4 a-4 b, 5 a-5 e, 6 as        well as any variations upon these and combinations, may, for        example, carry this information over the virtual channel        depicted in FIG. 17 (or alternative carry this information over        another channel distinct from the virtual channel depicted in        FIG. 17); and    -   The exemplary partition above with the SE running outside the        virtual machine will operate on any of the configurations        depicted in FIGS. 22 and 24, as well as variations on these and        combinations, and these configurations will operate in any one        or more of the configurations depicted in FIGS. 2-3, 4 a-4 b, 5        a-5 e, 6 as well as any variations upon these and combinations,        may, for example, carry this information over another channel        distinct from the virtual channel depicted in FIG. 17.

8. APPROACHES TO COMMUNICATION PROTOCOL FOR PARTITIONED MEDIA ENGINEIMPLEMENTATIONS

This section describes an exemplary software design for an exemplaryRemote Media Engine Protocol (RMEP) that can be used to extend areal-time interactive application comprising a media engine across a VDIconnection so that the portion of the media engine (TE) executing on theterminal platform can be controlled and interact with the portion ofmedia engine (SE) executing on the terminal platform and/or the GUIportion and other operational portions of the application.

In several places in this exemplary embodiment will provide aspects andelements particular to collaboration applications (for example, “call”),however these are provided merely an example and are readily omitted orreplaced with analogous (for example, “session,” query,” “calculate,”“update,” etc.) or alternate operations that may be relevant to othertypes of applications.

In an exemplary embodiment, RMEP is implemented as a library sittingfrom the Remote COM Proxy/Media Engine Host layer through the terminaltransportation layer. The Remote COM Proxy module implements theinterface proxy functionality for remote interfaces. In an embodiment,this “local proxy and remote implementation” functionality may be basedon the media engine API. In particular, RMEP will be based on the mediaengine API, with protocol requests, responses and notificationsgenerally having a one-to-one correspondence with API method calls,return values, and notification events: Using the RMEP client's APIs,the Remote Proxy module translates the COM method calls into RMEPmessages for requests, responses and notifications. Each COM method fromthe Remote COM Proxy has a corresponding RMEP method in the RMEP Clientlayer;

There will be two notable exceptions to this approach for protocoldesign:

-   -   RMEP will include the necessary support for connection        establishment, initial provisioning and session management.        These features are not applicable to the API itself.    -   RMEP messages will carry additional data values to ensure        efficient, bulk data transmission. For example, messages        corresponding to call state events will include the full set of        call status variables after the state change. The proxy        implementation of RMEP will cache this information and use it to        respond to property requests locally, rather than by making a        remote protocol call.

The Terminal Server Connector (TSC) and the Terminal Client Connector(TCC) represent the virtual transportation layer. The RMEP message isthe data format and is exchanged between the client server modules.

In review of above, the reader is again referred to FIG. 25, whichdepicts an exemplary block diagram illustrating an exemplary systemarchitecture provided for by the invention for enabling multimediaconferencing in a virtual desktop infrastructure environment.

8.1 Syntax

In an exemplary embodiment, each RMEP frame consists of a header, thepayload, and a trailer. In such embodiments, the header and trailer areeach represented using ASCII characters and terminated with a CRLF pair(0x0a 0x0d). Between the header and the trailer is the payload,consisting of zero or more bytes. An exemplary ABNF for the frame is:

frame = header payload trailer header   = keyword *attribute CRLFpayload   = *OCTET trailer   = *CRLF keyword   = “REQUEST” / “REPLY” /“NOTIFY” /   “FAULT” attribute   = “MsgId” COLON request_name /   “CSeq”COLON 1*DIGIT /   “PayloadSize” COLON 1*DIGIT /   “ContentType COLONcontent_type request_name  = “ICalls_CreateNewCall” / “ICall_Invite” /  “ICall_Hangup” /   more content_type  = “json” / “xml” COLON  = : more = {additional data}

8.1.1 Frame Header

In an exemplary embodiment, the frame header consists of a keywordfollowed by a bunch of “name:value” attributes separated by a singlespace character (decimal code 32, “ ”). The frame must start with akeyword which is one of “REQUEST”, “REPLY”, “NOTIFY”, “FAULT”, otherwiseit is considered to be an invalid RMEP message.

In an exemplary embodiment, there are header attributes specifyingmessage id, command sequence number, payload size, payload content type,and framing information. Exemplary header attributes are listed in thetable below:

Attribute Name (ASCII characters) Value (ASCII characters) RequiredMsgId ICalls_CreateNewCall/lCall_Invite Yes . . . CSeq  1 Yes (Not applyto NOTIFY) PayloadSize 32 Yes ContentType application/jsonapplication/xml Yes

Further exemplary features may include:

-   -   When receiving a request message with keyword REQUEST, the        system returns a response message with keyword REPLY or an error        message with keyword FAULT;    -   The MsgId attribute may be a pre-defined request or notification        name. (see Section 8.1);    -   The CSeq (Command Sequence) attribute may be arranged to be a        non-negative integer. A CSeq attribute in a response matches the        CSeq in the request;    -   There may be no CSeq attribute provided for NOTIFY messages;    -   The PayloadSize attribute is a non-negative integer and        specifies the number of bytes in the payload;    -   The ContentType attribute may be a predefined string such as        “application/json” or “application/xml” which specifies the        payload message type (for example, payload message type json).    -   The last 2 bytes of the header may be the CRLF (0x0d 0x0a).

8.1.2 Frame Payload

In an exemplary embodiment, the ContentType attribute in the headerrepresents the encoding/decoding payload type. The size of the payloadis also in the PayloadSize attributes from the header. Either JSON orXML message is supported.

8.1.3 Frame Trailer

In an exemplary embodiment, the frame trailer consists of 0 or more CRLFpairs. In an embodiment, when a received frame comprises charactersimmediately following the payload that do not correspond to a trailer,it is considered a bad frame.

8.2 Examples

In an exemplary embodiment for a collaboration application, thefollowing example shows an application sending a request to create a newcall (note that both header and trailer end with a CRLF pair):

Request message:    REQUEST MsgId:ICalls_CreateNewCalll CSeq:1PayloadSize:56    ContentType:application/json    {RemoteUrl:sip:joe@172.16.11.74,RemoteDisplayName: Joe} Response message:    REPLYMsgId: ICalls_CreateNewCalll CSeq:1 PayloadSize:6   ContentType:application/json    {S_OK}

It is noted, however, that the new call request operation is providedmerely an example and are readily omitted or replaced with analogous(for example, “session,” query,” “calculate,” “update,” etc.) oralternate operations that may be relevant to other types ofapplications.

In an exemplary embodiment, the following example is a remote propertyupdate containing two frames.

NOTIFY    MsgId:PropertyUpdate       PayloadSize:120ContentType:application/xml <Properties>   <Call>     <Count>1</Count>    <IsNewCallAloowed>true</IsNewCallAllowed>    <ReasonCode>3</ReasonCode>   </Call>   <Networking>    <State>0</State>      <ReasonCode>0</ReasonCode>     <SIPPort>5060</SIPPort>   </Networking> <Properties>

9. RMEP CLIENT FUNCTIONALITY

This section describes exemplary aspects of RMTP client functionality.

9.1 One-on-One COM Interface Correspondence

RMEP Client provides interfaces based on the Remote Media Engine COMAPIs, with protocol requests, responses and notifications. Each methodin the Remote COM Proxy has a corresponding RMEP method. Such as theRemote Call Proxy method from ICall “HRESULT Invite( )” has acorresponding mapping method RMEPClient::ICall_Invite( ).

The following lists provide an exemplary collection of RMEP Clientmethods:

- Interface: ICALL   HRESULT ICall_Invite( );   HRESULT ICall_Answer( );  HRESULT ICall_Refuse( );   HRESULT ICall_Hold( );   HRESULTICall_Resume( );   HRESULT ICall_Reinvite( );   HRESULT ICall_Transfer(const std::string& target, const   std::string& targetDisplayName); -Interface: INetworking   HRESULT INetworking_SetSIPSettings(conststd::string&   sDisplayName,  int  sipPort,  int  sipTransport,  int  maxSIPRequestSizeForUDP);   HRESULT INetworking_SetSIPUserAgent(conststd::string&   sUserAgent);

9.2 Caching Remote COM Properties

In an embodiment directed to reduce the overhead of remote protocolcall, an exemplary implementation provides for the proxy implementationof the RMEP Client to cache COM properties in those Remote COM Proxies.In an exemplary approach, the RMEP Client layer is responsible forparsing responses and notifications as well as accessing and/or updatingthe property members of proxy objects. For example if there is a callstate change on the remote terminal side, a notification carrying allcall properties is received by the RMEP Client and the properties in theRemotCallProxy object are updated.

10. RMEP CONNECTION ESTABLISHMENT SUPPORT

In an exemplary embodiment the RMEP provides the necessary support forconnection establishment. For Remote Restricted mode (see Section10.3.2), the RMEP layer passes RMEP message to the underliningconnection built by the Terminal Server Connector and the TerminalClient Connector modules. For the Pseudo Remote Mode, a TCP connectionis built directly between RMEP Client and Server layer.

10.1 Media Engine Build Version Check

To avoid unnecessary Media Engine build version conflict between theterminal client and terminal server during our internal development, anexemplary embodiment may include a build level and a build number checkas part of the connection setup process. For example, the terminalserver verifies and matches the build number of the connecting terminalclient only if the Terminal Client is a “debug” build (BuildLevel is‘d’).

As discussed in greater detail in Section 10.2, a version request issent first from the terminal server to the terminal client. The terminalclient sends back a response containing the supported RMEP Protocolversion information as well as the Media Engine build information. Whenthe terminal build level is ‘d’, then the terminal MediaEngine versionmatches in all respects viz. we need to compare the MediaEngine's major,minor, patch, level and build. The terminal server bypasses the check ifthe “Build-Level” is “r” (not “d”) and continues the RMEP versionnegotiation process (see Section 10.2).

As an example, here pertaining to when the terminal server and terminalclient are being connected, the terminal server sends a request with itsown RMEP protocol version information:

REQUEST   MsgId:VersionRequest   CSeq:1   PayloadSize:28ContentType:application/json {    Major: 1,    Minor: 0 }

The terminal client responses with Media Engine build information aswell as RMEP protocol information:

REPLY   MsgId:   VersionRequest   CSeq:1   PayloadSize:62ContentType:application/json {   MediaEngineVersion: 10.2.99.d.1 [DEBUG]  Major: 1,   Minor: 0 }

10.2 Protocol Version Negotiation

In an exemplary embodiment a protocol version negotiation is part of theconnection setup process. For example, when the RMEP Client and Serverare being connected, the RMEP Client first sends a version request withits own version information to the connecting RMEP Server, the RMEPServer either replies its own version or a FAULT response if the versionis higher and not supported. The RMEP Client disconnects the connectionif the Server's version is too old or uses the lowest version number forthe final version.

10.2.1 RMEP Server Version Decision

FIG. 26 provides an exemplary block diagram illustrating the RMEP Serverversion decision tree.

10.2.2 RMEP Client Version Decision

FIG. 27 provides an exemplary block diagram illustrating the RMEP Clientversion decision tree.

In an exemplary embodiment the RMEP Client and Server modules saves thefinal version that applies to the connection. Each RMEP version in RMEPClient is associated with a Request Command Set. For example, if theRequest Command Set's version is greater than the negotiated version,the whole request set is disabled.

The following example illustrates a case where the final version is 1.0:

REQUEST   MsgId:VersionRequest   CSeq:1   PayloadSize:28ContentType:application/json {   Major: 1,   Minor: 0 } REPLY   MsgId:  VersionRequest   CSeq:1   PayloadSize:28 ContentType:application/json{   MediaEngineVersion: 10.2.99.d.1 [DEBUG]   Major: 1,   Minor: 6 }

This example illustrates a case where the RMEP Server rejects anddisconnects the connection since RMEP server's version is only 1.6.

REQUEST   MsgId:VersionRequest   CSeq:1   PayloadSize:28ContentType:application/json {   Major: 2,   Minor: 0 } FAULT   MsgId:  VersionRequest   CSeq:1   PayloadSize:27 ContentType:application/json{Reason: protocol mismatch}

10.3 Connection Support

In this section exemplary aspects of connection support are provided.

10.3.1 Static Class Diagram

FIG. 13 illustrates an exemplary class diagram showing an aggregationassociation between the RMEPCIient object and the RMEPConnection object.

10.3.2 Remote Restricted Mode

In an exemplary embodiment operating under the Remote Restricted Mode,the connection is established through TSC and TCC. The RMEP Clientcreates a TSC object as a connection handler. The TSC layer providessend/receive and callback functions for the RMEP Client through thehandler.

In an embodiment, TCC is implemented a separated process.

10.3.3 Pseudo-Remote Mode

In an exemplary embodiment operating the Pseudo Remote Mode, there is noTSC and TCC involved. The RMEP Client spawns the Media Engine Hostprocess on the same machine and also passes the application host andport as command-line parameters using Windows CreateProcess system call.The spawned Media Engine Host application realizes it is under thePseudo-Remote mode, and the RMEP Server creates a connection to the RMEPClient using the RMEPConnection object as its connection handler for theTCP connection.

10.3.4 Keep Alive Support

In an exemplary embodiment the RMEP Client keeps sending KEEP-ALIVErequest to REMP Server. The RMEP Server echoes a response back. Forexample:

REQUEST   MsgId:KEEP-ALIVE   CSeq:67   PayloadSize:0ContentType:application/json REPLY   MsgId:KEEP-ALIVE    CSeq:67   PayloadSize:14 ContentType:application/json {KeepAlive:OK}

10.3.5 Threading

In an exemplary embodiment the RMEP server uses the same dispatcherthread which is used for receiving requests to notify Media Engine Hostfor the request processing. The Media Engine Host needs to return thedispatcher as soon as possible (no blocking is allowed).

11. RMEP TRANSACTIONS

In an exemplary embodiment the RMEP Client maintains a list of ongoingtransactions to track the status of each sending request and receivingresponse, and the RMEP Server keeps a list incoming transactions forprocessing requests. The transaction layer of RMEP reports any problemregarding to the underneath connection, missing response or timeoutrelated events.

11.1 Class Diagram

FIG. 14 illustrates an exemplary class diagram showing the RMEP Clientmaintaining a list of ongoing transactions to track the status of eachsending request and receiving response, and the RMEP server keeping alist of incoming transactions.

11.2 Transaction State

In an exemplary embodiment the states for RMEP Client transaction may bedefined and arranged as listed below:

IDLE->TRYING->COMPLETED IDLE: Initial state. TRYING: The transactionstarts. COMPLETED: Received the response.

In an exemplary embodiment the states for a RMEP Server transaction maybe defined and arranged as listed below:

IDLE -> TRYING->COMPLETED IDLE: Initial state. TRYING: The transactionstarts. COMPLETED: Transmitted the final response.

11.3 Transaction Call Backs

In an exemplary embodiment the RMEP parser parses the receiving RMEPmessage and creates an either RMEP Client or Server transaction. TheRMEP MsgID and CSeq attributes are the key matching a new or existingtransaction.

In an exemplary embodiment OnRequest( ) and OnResponse( ) is providedfor following (an) event processing step(s).

In an exemplary embodiment error handling callbacks such as OnTimeout,OnDisconnected( ) may also be provided.

12. APPROACHES TO DEPLOYING TWO-COMPONENT PARTITIONED MEDIA ENGINES

Attention is now directed to exemplary approaches to deployingtwo-component partitioned media engines, beginning with a review of thepreviously presented exemplary arrangements depicted in FIGS. 8 and22-24, and another example alternative embodiment depicted in FIG. 28.

FIG. 8 illustrates an exemplary deployment of a two-componentpartitioned media engine wherein each server ME instance runs in avirtual machine on the server platform. Each server ME instance iscoupled with a terminal ME instance executing on the correspondingterminal platform but not within the terminal client session.

FIG. 22 illustrates an alternative exemplary arrangement similar to thatof FIG. 8 but wherein server ME instances do not execute on virtualmachines but rather on a special server.

FIG. 23 illustrates another alternative exemplary arrangement similar tothat of FIG. 8 but wherein terminal ME instances execute within terminalclients (rather than parallel to them).

FIG. 24 illustrates yet another alternative exemplary arrangementcombining the server side modifications of FIG. 22 and the terminal sidemodifications of FIG. 23.

FIG. 28 illustrates an alternative embodiment similar to that of FIG. 8but wherein each server ME instance runs on a dedicated server ratherthan on a virtual machine in the server.

Various embodiment of the inventive concept provide for additionalvariations that are possible as would be apparent to persons of skilledin the art. These are provided for by the invention.

Various embodiment of the inventive concept further provide for two ormore the various exemplary embodiments depicted in FIGS. 8 and 22-24, aswell as any variations on them, to be implemented in co-existingcombination. These are provided for by the invention.

Various embodiment of the inventive concept further provide for two ormore the various exemplary embodiments depicted in FIGS. 8 and 22-24, aswell as any variations on them, to be implemented in interworkingcombination. These are provided for by the invention.

Various embodiment of the inventive concept further provide for any ofthe arrangements of FIGS. 8 and 22-24, as well as any variations onthem, to be implemented in any one or more of the configurationsdepicted in FIGS. 2-3, 4 a-4 b, 5 a-5 e, 6 as well as any variationsupon these and combinations. These are provided for by the invention.

It is explicitly noted that the exemplary partition above with the SErunning on the virtual machine will operate on any of the configurationsdepicted in FIGS. 8 and 23, as well as variations on these andcombinations, and these configurations will operate in any one or moreof the configurations depicted in FIGS. 2-3, 4 a-4 b, 5 a-5 e, 6 as wellas any variations upon these and combinations. The full range of thesemany possibilities and there natural extensions are anticipated andprovided for by the invention.

Additionally, it is explicitly noted the exemplary partition above withthe SE running outside the virtual machine will operate on any of theconfigurations depicted in FIGS. 22 and 24, as well as variations onthese and combinations, and these configurations will operate in any oneor more of the configurations depicted in FIGS. 2-3, 4 a-4 b, 5 a-5 e, 6as well as any variations upon these and combinations. The full range ofthese many possibilities and there natural extensions are anticipatedand provided for by the invention.

13. EXEMPLARY IMPLEMENTATIONS

This section provides examples showing how the present invention canaddress the challenges of delivering real-time media interactivecollaboration applications in stand alone as well as an extremely widerange of VDI and VAI arrangements that are easily administered. Ingeneral the examples are based on the following concepts:

-   -   A Media Engine is implemented with auto-dividing capabilities        such as those described in Section 14;    -   As possible, the software may be implemented so as to        additionally auto-configure lower-level details responsive to        the terminal platform it is executing on;    -   When in stand-alone mode (i.e., in an environment such as FIG.        1), a single instance of the Media Engine;    -   When in VDI/VIA mode (i.e., in an environment such as FIG. 2 and        the many variations subsequently discussed):        -   The real-time high-bandwidth high-CPU-usage components of            the Media Engine may be deployed in a Media Engine instance            on the remote terminal device (rather than executing on a            VDI server);        -   A protocol, such as the exemplary Remote Media Engine            Protocol (RMEP) described in Section 11, extends the Media            Engine interface across a VDI connection and allows            terminal-side instance of the Media Engine to be controlled            remotely by the application across a VDI channel.

In one or more embodiments of the invention, there may be multipleimplementations of the Terminal Server Connector and Terminal ClientConnector modules for example, different versions for CITRIX®, HP®, and“pseudo-remote” modes of operation. Various degrees of specific remoteterminal platform functionality may be encapsulated in these modules asadvantageous and/or as possible.

In one or more embodiments of the invention, an exemplary Media Engineembodiment may comprise two modes, “Auto” and “Restricted” based on twodifferent COM ClassIDs. In such an embodiment:

-   -   the Media Engine Host application running on the Terminal Client        always starts the MediaEngine in the “Restricted” mode, which        has restricted media engine functionalities like lack of Address        Book, Call Logging etc; and    -   the Media Engine started in “Auto” mode will detect the mode        automatically which could be local, pseudo-remote, CITRIX® or        HP®. We will use a DeploymentMode registry key to specify if        Media Engine needs to run in pseudo-remote mode, which will be        used for testing the Remote Terminal internally.

[HKEY_CURRENT_USER\Software\Avistar\MediaEngine]“DeploymentMode”=“remote”

In one or more embodiments of the invention, CITRIX® or HP® sessions maybe identified via detection by their respective APIs. In such anembodiment, the Media Engine may run in local mode if it cannot detect apseudo-remote, CITRIX® or HP® mode.

In one or more embodiments of the invention, the CITRIX® Terminal ClientConnector may be realized as a Virtual Channel Driver DLL. In anexemplary embodiment, the “pseudo-remote” TCC will be linked into theMedia Engine Host executable.

In one or more embodiments of the invention, the Terminal ServerConnector code should be written to use dynamic rather than staticlinkage to terminal server API functions. This will allow a single MediaEngine binary to work on all systems, whether or not they have theterminal server libraries installed or accessible. FIG. 29 depicts anexemplary logical representation of terminal access type handling asprovided for by the invention. FIG. 30 depicts an exemplaryimplementation of terminal access type handling as provided for by theinvention.

FIG. 31 depicts exemplary media engine initialization handling inaccordance with one embodiment. For example, in an embodiment,initializing a media engine instance in proxy mode will result in alsoinitializing the C3 Media Engine running on a terminal client. Thisremote initialization scenario introduces a number of failure conditionsthat could to be reported through the user interface. As an example, inthe event the remote ICA Client does not have a media engine installed,an error must be reported which can be processed by initializing theapplication to present an error message to the user along with any otherimplementation desired to track the condition such as logging the eventto a file.

FIG. 32 depicts an exemplary media engine auto-recovery sequence asprovided for by the invention.

Using this general framework or variations upon it, exemplaryembodiments of the invention directed to the following vendor VDI andVAI offerings are considered:

-   -   CITRIX®    -   HP®    -   WYSE® “thin client” terminals    -   MICROSOFT® OCS

These discussions are provided below.

13.1 Citrix®

The following nomenclature is introduced for discussing exemplaryimplementations software embodiments on servers:

-   -   Parent Application: the application that needs to run on        CITRIX®. In an exemplary embodiment, the same Parent Application        software will support both VDI and fat client deployments.    -   Media Engine in Proxy Mode: In an embodiment, this is the Media        Engine extended with a “proxy” mode that allows it to send        requests to a remote instance of Media Engine across the ICA        channel. In an embodiment, the resulting arrangement implements        the server-side of the RMEP protocol.

The following nomenclature is introduced for discussing exemplaryimplementations software embodiments on remote terminals:

-   -   Media Engine Host: In an embodiment, this is the executable that        hosts C3 Media Engine on the remote terminal. It is responsible        for instantiating the C3 Media Engine COM object and it waits        for connections from the AVISTAR® CITRIX® Client Plug-In. Media        Engine Host also implements the client-side portion of the        Remote Media Engine Protocol.    -   Media Engine for Terminals: In an embodiment, is a Media Engine        optimized for thin terminals which typically have lower CPU        capabilities than traditional PCs.    -   ICA Client Plug-In: In an embodiment, this is software that        plugs into the ICA client software and creates a Virtual Channel        across the ICA protocol. This virtual channel is used to relay        messages between the Media Engine Host and the Parent        Application running on the CITRIX® server.

These can be used to construct exemplary embodiment architectureswherein a remote terminal Media Engine plugs into application softwarerunning on the server using the same interfaces as those of the standardMedia Engine, but all interface requests are relayed to the client-basedMedia Engine module using a connection manager protocol such as theCITRIX® ICA protocol:

-   -   In one or more embodiments of the invention, the remote terminal        Media Engine transmits compressed video directly from the user        terminal and avoids sending uncompressed video over the network.        This makes the solution work in WAN environments and allows        scaled deployments in LAN environments.    -   In an embodiment, the remote terminal Media Engine routes        audio/video directly between clients over UDP and bypasses        TCP-based VDI protocols entirely, thereby allowing voice and        video traffic to take advantage of underlying QoS        infrastructure.    -   In an embodiment, the remote terminal Media Engine relegates        audio/video compression and decompression from the CITRIX®        server to the user device, thereby significantly increasing the        scalability of the solution.

In one or more embodiments of the invention, all functionality relatedto managing collaboration application calls and associated media streamsare deployed on the terminal while non media-related functionalityexecute on the CITRIX® server to preserve the benefits of centralizedapplication delivery. For example, the address book of a collaborationapplication can, in an embodiment, be implemented as a standalone pieceof code that should run on the server rather than on the desktop.

FIG. 33 shows a general exemplary arrangement delivering the solutionsprovided by the invention to CITRIX® environments. More specifically,CITRIX® provides a broad variety of mechanisms for deliveringapplications and desktops. These mechanisms are largely based on twoproduct approaches:

-   -   XenApp    -   XenDesktop

13.1.1 XenApp Deployments

With XenApp, users use ICA client software to connect to a XenApp serverrunning on WINDOWS® Server 2003 or WINDOWS® Server 2008 to accessapplications on that server or the entire server desktop. LeveragingTerminal Services (on WINDOWS® 2003) or Remote Desktop Services (onWindows 2008), XenApp allows different users to connect to the sameserver at the same time. In a typical deployment, a single XenApp servercan support up to 500 users. CITRIX® typically refers to XenApp-baseddeployments as Hosted Shared Apps or Hosted Shared Desktops.

13.1.1.1 Hosted Shared Apps—Single XenApp Server

This is the simplest scenario. Here all users in a XenApp deploymentconnect to the same XenApp server, as shown in FIG. 34. XenAppdeployments create a number of potential implications. As stated before,all users connected to a XenApp server share the same underlying server.As a result, multiple users may run the same application on that serverat the same time. In order to support XenApp, applications must bedesigned to support running multiple instances of that application onthe same machine at the same time. Potential areas of concern related tothis architecture and addressed by the invention include the following:

-   -   Port conflicts: multiple application instances trying to use the        same IP ports;    -   Access to registry: multiple application instances sharing the        same registry hive;    -   Access to configuration files: multiple application instances        sharing the same configuration files;    -   Access to COM objects: multiple application instances        instantiating the same COM objects;    -   Access to data files: multiple application instances accessing        the same data files;    -   Access to log files: multiple application instances writing to        the same log files.

13.1.1.2 Hosted Shared Desktops—Single XenApp Server

From a deployment point-of-view, this scenario is almost identical tothe Hosted Shared Apps scenario, except that the entire server desktopis accessed rather than individual applications. This results in a userexperience that is similar to XenDesktop (described later) although thedesktop is shared with other users (hence the term Hosted SharedDesktops) rather than dedicated to a specific user.

13.1.1.3 Hosted Shared Apps and Desktops—Multiple XenApp Servers

Since a typical XenApp server supports about 500 users, scaleddeployments require multiple XenApp servers. CITRIX® organizes XenAppservers in a server farm. Load balancing infrastructure is used todistribute the users among the set of available XenApp servers in afarm. Note that in a typical deployment, XenApp servers are virtualized.

Deploying multiple servers introduces a number of issues, since there isno guarantee that a user will connect to the same server every singletime. To ensure that users have an identical experience independent ofwhich XenApp server they connect to, all XenApp servers must haveidentical software images (i.e. they must run the same OS, have the sameapplications installed, have identical configuration information, etc.)

To avoid the management hassles associated with trying to maintainidentical software images on different machines, CITRIX® allows serversto boot from virtual disks (vDisk) provided by a Provisioning Server(PVS) across the network. Multiple XenApp servers can boot from the samevDisk which ensures identical images for those servers. ProvisioningServer provides tools that allow administrators to create and managevDisks. The vDisks can be configured in three different modes:

-   -   Standard vDisks are effectively read-only: all server writes to        vDisk are stored in a unique local change file (the write cache)        that is destroyed upon each server reboot.    -   Private vDisks support read/write operation: each server has a        dedicated vDisk image configured in a read/write fashion. All        changes to the vDisk are propagated back to the Provisioning        Server and become part of the vDisk image. This makes it        impossible to share vDisks between different servers,        eliminating most of the benefits of vDisks.    -   Differential vDisks are a hybrid of standard and private vDisks:        each server stores vDisk writes into a unique local change file        that survives server reboots, allowing servers to keep        configuration changes. However, these changes are discarded        whenever the base vDisk is modified on the Provisioning Server.

CITRIX® Best Practice is to use Standard vDisks, effectively disallowingwrite operations to the base image. This configuration is shown in FIG.35.

For Hosted Shared Apps using multiple XenApp servers with StandardvDisks, this has the following implications:

-   -   Persistent user data (such as user-specific configuration        settings, user preferences, applications-specific data, etc.)        must be stored in the user's Profile or on network disks that        store user-specific data (typically SANs are used to make user        data available to all XenApp servers in a farm). Moreover, users        need to be set up with Roaming Profiles to make sure their        profiles follow them no matter which server they log into.    -   Application-generated files (such as log files, audit logs, call        detail records) that need to survive server reboots cannot be        stored locally on the server, since server reboots will restore        the standard vDisk image, thereby erasing all previously written        data.

13.1.2 XenDesktop Deployments

To avoid many of the challenges associated with sharing applications anddesktops on the same server using XenApp, CITRIX® introduced XenDesktopas an alternative technology. With XenDesktop, users use ICA clientsoftware to connect to an entire desktop (physical or virtual) that isdedicated to that individual for the duration of the session.

In one or more embodiments of the invention, as far as softwareapplications are concerned, this deployment is similar to running on adedicated desktop at the user's desk, except that the desktop is locatedin a data center and accessed remotely using the ICA protocol. As aresult, applications typically do not need to be certified to be“XenDesktop Ready”.

CITRIX® typically refers to XenDesktop-based deployments as HostedDesktops (as opposed to the Hosted Shared Desktops provided by XenApp).These scenarios are explored further in the remainder of this section.

13.1.2.1 Hosted VM-Based Desktops

In the Hosted VM-Based Desktop scenario, each user's desktop runs in itsown virtual machine, enabling multiple users to share a single physicalserver while running their environments in isolation from one-another.As compared to XenApp shared desktops, this solution affords each userthe more personalized Windows desktop experience that is typicallyneeded by office workers. More importantly, by assigning dedicateddesktop to each user, XenDesktop avoids all the problems associated withrunning multiple instances of an application running on the same machineat the same time. This scenario is shown in FIG. 36.

In a typical deployment, a single physical server can support about 50simultaneous virtual desktops, so the scalability of this solution isnot quite as good as XenApp. Moreover, XenDesktop requires management ofeach user's desktop, whereas XenApp is limited to managing just theserver images. Provisioning Server is typically used to allow all usersin the same group to use the same vDisk image, which simplifies desktopmanagement. As with XenApp, Standard vDisk is the recommended scenario.This means that XenDesktop deployment scenarios impose all the samerequirements on application-specific data as the Multiple XenApp Serverscenarios.

13.1.2.2 Hosted Blade PC Desktops

This scenario is exactly like VM-based desktops, but running ondedicated hardware instead. As a result, there is one user per hostedblade PC. This scenario imposes the fewest restrictions, but it is notvery commonly used because of scalability limitations.

13.1.3 Mixed XenDesktop/XenApp Deployments

This scenario, shown in FIG. 37 is often referred to as Virtual Apps toHosted Desktops, and is a combination of the XenApp and XenDesktopscenarios described above. In this scenario, CITRIX® is configured to:

-   -   Deliver hosted desktops (VM or blade) to users. These hosted        desktops are typically configured with applications that are        common to all users, allowing administrators to manage a very        small number of vDisks for hosted desktops.    -   Deliver hosted applications into these hosted desktops. This        allows administrators to deliver applications selectively to        specific groups of users without having to create separate        vDisks for each group of users.

This is the most common Citrix deployment scenario since it combines thescalability and management benefits of XenApp with the personalizationand isolation benefits of XenDesktop. However, it is also the mostcomplex scenario. From a technical point-of-view, applications deliveredthrough this mechanism incur a double ICA hop, since users access theirhosted desktops across one ICA link, while those desktops access hostedshared applications across a second ICA link. Consequently, while theoverall solution should be designed with this scenario in mind, mixedXenApp/XenDesktop deployments do not need to be supported in the firstrelease of C3 Integrator—CITRIX® Edition.

13.1.4 Streamed Applications and Desktops

This is a model of application and desktop virtualization that does notinvolve the ICA protocol, but rather relies on “network boot” conceptsthat provide a local desktop experience to the end-user but allowscentralized management of the desktop. Again, Provisioning Server in thedatacenter is used to stream the desktop to users' physical PCs whenthey boot up.

Given that this deployment scenario does not involve the ICA protocol,it is outside the scope of this document. However, given that Avistarwill need to operate correctly in Standard vDisk environments to supportthe various ICA-based deployment scenarios, it is expected thatvirtualization scenarios based on streaming “will just work.”

13.2 VMware

In an embodiment, a VMware VDI implementation may be implemented in wayssimilar to the CITRIX® implementation. Some VMware-specific adaptationsprovided for by the invention include:

-   -   Differences in window management and window geometry updating to        remote terminal clients;    -   VMware View software to access Windows applications running on        VMware servers from VMware View clients;    -   Adaptation of the RMEP protocol to VMware's PCoIP protocol.

13.3 HP

In an embodiment, an HP VDI implementation may be implemented in wayssimilar to the CITRIX® implementation. Some HP specific adaptationsprovided for by the invention include:

-   -   Differences in window management and window geometry updating to        remote terminal clients;    -   RGS software to access Windows applications running on RGS Blade        Servers from HP RGS Terminals;    -   Leveraging of RGS support for “collaboration” vs. “regular”        modes of remote desktop access.

13.4 WYSE®

The intention for supporting virtual desktop sessions using CITRIX®,HP®, or other commercial solutions is for the application to be ashardware independent as for any workstation deployment. In that respect,there should be no need to state specific requirements related toparticular thin client terminal model any more than such requirementswould be necessary for development of an application intended to rununder Windows.

WYSE® sells a number of thin client devices as summarized in thefollowing table. There are four basic models based on 4 different CPUfamilies, resulting in four different performance profiles. For each ofthese models, different operating environments are supported.

Processor AMD Via C7 Geode GX Eden - 1 GHz AMD 366 MHZ VIA 1 GHz 800 MHzSempron WYSE ®ThinOS S10 V10 WINDOWS ® CE S30 C30LE V30 LINUX ® S50 V50R50 WINDOWS ® XPe C90LE V90 R90

Only the high-end R class terminals are capable of supporting 30 fpsvideo. Although WYSW® terminals are available with multiple embeddedsoftware choices (WYSE®ThinOS, WINDOWS® CE, LINUX®, WINDOWS® XPe,WINDOWS® Embedded Standard), the most predominant platform appears to beWINDOWS® XPe (WINDOWS® XP embedded).

Various embodiments of the inventive concept further provide foroperation using such WYSE® “thin client” terminals.

13.5 Microsoft® OCS

Various embodiments of the inventive concept further provide for fullaudio and video support for OCS on CITRIX® to present users with asimple launch of the software from OCS and to embed the software withinthe OCS look and feel. An example of the user experience may be similarto that shown earlier in FIG. 15.

Launching the application direct from within the MICROSOFT® OSC (MOC)client using menu extensions within MOC with the Contacts List extendedwith an option to start an audio/video conference provided by theinvention with the selected contact(s). No additional presence ordirectory subsystem need be provided since all presence and contactinformation is entirely managed through and obtained from MICROSOFT®OCS.

FIG. 38 depicts an exemplary MOCA startup sequence as provided for bythe invention.

FIG. 39 depicts an exemplary MOCA exit sequence as provided for by theinvention.

In one or more embodiments of the invention, server-based integration isbased on Remote Call Control (RCC). When Office Communicator isconfigured for Remote Call Control MOC users will continue to use theexisting MOC GUIs to place calls, but rather than using the built-in MOCA/V IP clients, calls are placed using the media engine. This providesthe end-user with an experience that is as close as possible to theend-user experience provided by MOC. Note that if RCC is already in usefor other applications (e.g. to integrate with PBX infrastructure),MICROSOFT® OCS Server Plug-Ins are used to mimic a Remote Call Controlexperience.

The invention also allows users to take advantage of all MICROSOFT® OCSfunctionality—including voice and video chat—even in CITRIX®environments.

In addition to calling integration through RCC and Action Menuextensions, various embodiments of the invention also provide thefollowing additional integration points:

-   -   Multiple available presence states to show when a user can be        reached via the solution;    -   The application GUI controls can be provided in a custom tab;    -   Seamless and immediate access to any other types of A/V endpoint        within customers' voice and video networks.

14. AUTO-DIVIDING TWO-COMPONENT PARTITIONED MEDIA ENGINE ACCORDING TOEXECUTION PLATFORM

Referring to the exemplary architecture of a contemporaryhigh-functionality real-time interactive collaboration application,various adaptations must be made for the various platforms and casesdescribed thus far. For example:

-   -   When the exemplary FIG. 15-16 application executes solely on a        traditional stand-alone computer such as that suggested in FIG.        1, the media engine does not need to be partitioned and further        done not require a virtual channel driver, and as such can        operate as depicted in FIG. 16. This case is represented in FIG.        40 a wherein the full FIG. 16 architecture is implemented but a        possible virtual channel driver is not (depicted by the “X”        cross-out over the VC element);    -   For the portion of the exemplary FIGS. 15-16 application        executing on a VDI terminal, be it executing in parallel to the        terminal client (as in FIGS. 8 and 22) or within the terminal        client (as in FIGS. 23 and 24), the GUI component, COM        interface, contacts element, and associated external elements        are not implemented and the virtual channel driver is        implemented. This case is represented in FIG. 40 b depicting        corresponding “X” cross-outs over the unimplemented elements and        the virtual channel driver depicted with no “X” cross-out;    -   For the portion of the exemplary FIG. 15-16 application        executing on a traditional

VDI virtual machine server session (as in FIGS. 8 and 23), the media andcontrol elements are not and the virtual channel driver is implemented.This case is represented in FIG. 40 c depicting corresponding “X”cross-outs over the unimplemented elements and the virtual channeldriver depicted with no “X” cross-out;

-   -   For the portion of the exemplary FIGS. 15-16 application        executing on a simplified VDI virtual machine server session (as        in FIGS. 22 and 24), the media, control, contacts, outside        utilities and virtual channel driver elements are not        implemented and the virtual channel driver is implemented. This        case is represented in FIG. 40 d depicting corresponding “X”        cross-outs over the unimplemented elements;    -   For the portion of the exemplary FIGS. 15-16 application        executing on a SE server, (as in FIGS. 22 and 24), the GUI        component, COM interface, media element, and control elements        are not implemented and the virtual channel driver is        implemented. This case is represented in FIG. 40 e depicting        corresponding “X” cross-outs over the unimplemented elements and        the virtual channel driver depicted with no “X” cross-out.

In one or more embodiments of the invention, a single media enginearticle of software is deployed as a general-purpose SIP voice and videoengine with the goal of being integrated with a variety of othertechnologies. In such embodiment or variations upon it, the media enginehas the following characteristics:

-   -   Functionality is delivered entirely through APIs. The GUI to        these features is provided on top of APIs directly by the        embedding application, or existing GUIs are customized to fit        the look-and-feel of the embedding application;    -   Audio support includes one or more of G.711, G.722, G.722.1c,        and AAC-LC for audio calls from 3 kHz to 14 kHz        (ultra-wideband);    -   Video support includes one or more of H.264, H.263+, and H.263        for video with rates ranging from 128 kb/s to 2048 kb/s. Video        is encoded at up to 30 fps (depending on the webcam used);    -   The Avistar C3 Media Engine includes HD support. Supported video        resolutions:        -   HD 720P (1280×720 pixels)        -   4CIF resolution (704×576 pixels)        -   VGA resolution (640×480 pixels)        -   400×244 pixels        -   CIF resolution (352×288 pixels) or SIF (352×240)        -   QCIF resolution (176×144 pixels) or QSIF (176×120)    -   Video is transmitted over RTP;    -   daptive jitter buffer, packet loss concealment, call rate        adaptation, and other techniques are used to preserve quality of        service;    -   Standards-based firewall traversal (using STUN, TURN, and ICE)        are provided.

In an embodiment, a common article of software automatically configuresitself at installation, or at a later time, so as to implement selectedelements and not implement other elements according toautomatically-provided platform information. This is illustrated in FIG.41 a. Examples of automatic configuration based on platform informationincludes:

-   -   Choice of target system load level for dedicated desktops,        virtual desktops, shared-use systems or remote terminals;    -   Choice of video resolutions and frame rates based on available        CPU, GPU or DSP resources or video camera capabilities;    -   Choice of the audio sampling frequency to create the right        tradeoff between system load and audio quality;    -   Availability of certain quality enhancement algorithms, such as        video noise filtering or acoustic echo cancellation, based on        available hardware and computing resources.

In one or more embodiments of the invention, a common article ofsoftware may automatically configure itself at installation, or at alater time, so as to implement selected elements and not implement otherelements according to administrator-provided set-up information. This isillustrated in FIG. 41 b. Examples of automatic configuration based onadministrative information may include:

-   -   Features enabled or disabled based on per-terminal licensing,        for different terminals used to access the same set of systems        or applications;    -   Features enabled or disabled based on per-application licensing,        for different applications using the same partitioned article of        software;    -   Features enabled or disabled based on end user entitlement, for        different users accessing the same system, application, or        terminal.

In an embodiment, a common article of software may automaticallyconfigure itself at installation, or at a later time, so as to implementselected elements and not implement other elements according to bothautomatically-provided platform information and administrator-providedset-up information. This is illustrated in FIG. 41 c.

15. APPROACHES TO MULTI-COMPONENT PARTITIONED MEDIA ENGINE SOFTWAREIMPLEMENTATION

Throughout Sections 4-14, the partition of the media engine into twosections, a first portion best suited for execution at the terminalplatform and a second best suited for execution at the server platformwithin VDI and VAI architectures, as presented in detail. Such a two-waypartition has a strong advantage for the current state of serverhardware and software, desktop computing terminal hardware, applicationsoftware, and administration environments such as the VDI and VAIarchitectures that have been considered. The added capability to allow asingle article of such software to auto-divide, auto-configure, and/orset-up configure so as to best match the underlying platform,networking, and distributed processing environment and/or otherdirectives provides considerable ease of installation, administration,version minimization, and other important value.

As mentioned earlier, these principles and approaches need not belimited to a two-component partition. In particular, in one or moreembodiments of the invention, a number of other rapidly evolving trendscurrently in place are excellent candidates for eventually beingwell-served by a multi-component partition, and further for these to berendered from article of such software to auto-divide, auto-configure,and/or set-up configure so as to best match the underlying platform,networking, and distributed processing environment and/or otherdirectives. These trends include:

-   -   Multi-core computing platforms (for example, media engines may        execute on one or more cores at high utilization with affecting        processes on other cores);    -   The rise of the extra computer power for Graphical Processing        Units (GPUs) and forays into their use in general computing;    -   General and specialized (for example compression, decompression)        DSPs;    -   Network distributed processing server architectures for        mash-ups;    -   Need for network based support of modest-CPU mobile devices.

Various embodiments of the inventive concept further provide formulti-component partitions of a single article of software.

Various embodiments of the inventive concept further provide for themulti-component partitions to be rendered from article of such softwareby any one or more of:

-   -   an auto-divide operation;    -   an auto-configure operation; and/or    -   a set-up configure operation,

so as to best match the underlying platform, networking, and distributedprocessing environment and/or other directives.

Various embodiments of the inventive concept further provide forterminal session software elements of such arrangement to be radicallydissimilar. For example:

-   -   In a remote medicine system one terminal session software        element may be specially configured specially for interfacing        with a patient and associated real-time physiological medical        measurement instruments, another configured specially for        interfacing with an analyzing physician, and perhaps a third        configured specially for a specialized facility device such as        an MRI machine in a room that the patient has been brought to;    -   In a telemetry situation for manufacturing plant operations or        environmental monitoring, various terminal session software        elements may operate in 2-way modes for interfacing with machine        sensors, environment sensors, operating personal, field        observers, etc.

In the exemplary two-component partitions of Sections 4-14 the partitionwas not explicitly organized as either a peer or hierarchical partition(although it could be structured in some such manner should that beadvantageous). However, many of the motivating trends listed at thebeginning of this section may in some circumstances lead themselves to amore organized peer or hierarchical partition.

As examples of usage, a terminal platform may be found upon installationor provisioning to comprise any one or more of:

-   -   Multicore CPU;    -   GPU;    -   General and specialized (for example compression, decompression)        DSPs;    -   Presence of classes of peripherals (for example, webcam,        headset, sensor interface); and/or    -   Special properties of peripherals (for example, webcam may        include video compression).

By way of example:

-   -   FIG. 42 depicts an exemplary peer-partition of a common article        of software that would otherwise execute unpartitioned on a        single desktop platform such as that depicted in FIG. 1;    -   FIG. 43 depicts an exemplary hierarchical-partition of a common        article of software that would otherwise execute unpartitioned        on a single desktop platform such as that depicted in FIG. 1;    -   FIG. 44 depicts an exemplary mixed-partition (i.e., partially        peer-partitioned, partially hierarchical-partitioned) of a        common article of software that would otherwise execute        unpartitioned on a single desktop platform such as that depicted        in FIG. 1.

Other combinations and variations that are clear to one skilled in theart are anticipated and provided for by the embodiments of theinvention.

Various embodiments of the inventive concept also provide for automaticor administered peer-partition of a common article of software so as tobest match the underlying platform, networking, and distributedprocessing environment and/or other directives.

Various embodiments of the inventive concept additionally provide forautomatic or administered partition of a common article of software soas to best match the underlying platform, networking, and distributedprocessing environment and/or other directives.

Various embodiments of the inventive concept further provide forautomatic or administered mixed-partition of a common article ofsoftware so as to best match the underlying platform, networking, anddistributed processing environment and/or other directives.

As an example of some of the aforedescribed automatic partitionpossibilities, consider some exemplary cases wherein the endpoint deviceoperating as a VDI-client terminal may in some cases interface withperipheral or internal media devices that may or may not additionallyinclude one or more of compression and/or decompression capabilities. Inthe figures to follow, the audio/video media element of the inventivearticle of 2-way A/V software at the endpoint device is furtherstructurally segregated into four components:

-   -   Video compression;    -   Audio compression;    -   Video decompression; and    -   Audio decompression.

To begin, consider the possible endpoint device cases wherein (1) anexternal webcam with internal microphone or (2) an external webcamwithout a microphone together with a headset or (3) a built-in webcamand microphone are made available to at an endpoint device operating asa VDI-client terminal, and wherein one instance of an inventive articleof 2-way A/V software is installed on the endpoint device and anotherinstance of the same article of 2-way A/V software is installed on theassociated server. This overall situation (and many possible variations)is represented by FIGS. 45-47. The general situation regarding the autopartitioning was considered earlier, for example in conjunction withFIGS. 40 b-40 c and FIGS. 40 d-40 e. Although the arrangement of FIGS.45-47 depicts the particular client/server automatic partition outcomeassociated with FIGS. 40 b-40 c, it is to be understood that wideallowances for other client/server automatic partition outcomes, such asthe client/server automatic partition outcome associated with FIGS. 40d-40 e, are implied, anticipated, and provided for by the invention.

More specifically:

-   -   FIG. 45 depicts an exemplary arrangement wherein an external        webcam with internal microphone is made available to at an        endpoint device operating as a VDI-client terminal, and wherein        one instance of the inventive article of software is installed        on the endpoint device and another instance of the same article        of software is installed on the associated server. The same        software architecture is relevant if the webcam and mic are        integrated into a computer monitor.    -   FIG. 46 depicts an exemplary arrangement wherein an external        webcam without a microphone used together with a headset are        made available to at an endpoint device operating as a        VDI-client terminal, and wherein one instance of the inventive        article of software is installed on the endpoint device and        another instance of the same article of software is installed on        the associated server.    -   FIG. 47 depicts an exemplary arrangement wherein a built-in        webcam and microphone are made available to at an endpoint        device operating as a VDI-client terminal, and wherein one        instance of the inventive article of software is installed on        the endpoint device and another instance of the same article of        software is installed on the associated server. Here the        endpoint device may be a laptop computer (as depicted), tablet        computer, etc. comprises an internal microphone and internal        speaker as well as internal audio compression and internal audio        decompression.

Next to be considered are exemplary variations wherein the webcam and/orheadset include media compression/decompression capabilities that couldbe exploited so as to offload media CPU loading at the endpoint deviceoperating as a VDI-client terminal.

FIG. 48 depicts in more detail wherein a peripheral webcam furthercomprises internal video compression. Under the circumstance wherein theinventive article of software detects that the webcam comprises internalvideo compression, the invention provides for the video compressionelement within the inventive article of 2-way A/V software the endpointdevice not be enabled/initialized.

FIG. 49 shows an exemplary variation on the situation depicted in FIG.48 wherein a webcam further comprises both an internal microphone andinternal audio compression. Under this circumstance (wherein theinventive article of software detects that the webcam comprises bothinternal video compression and internal audio compression), theinvention provides for both the video compression element and audiocompression element within the inventive article of 2-way A/V softwarethe endpoint device not be enabled/initialized. It is noted that such anarrangement may not be practical in situations wherein received audio isreproduced by an acoustically proximate speaker and 2-way audio echocancelling is employed. However, such a situation may be advantageous insome settings, for example in the case of using the inventive article of2-way A/V software for creating an A/V recording or a 1-way “webcast”broadcast. The endpoint device may comprise a laptop computer, tabletcomputer, or computer monitor comprising an internal microphone andinternal speaker as well as internal audio compression and internalaudio decompression. For example, an internal audio card in a laptop ortablet computer can provide internal audio compression, and internalaudio decompression. Under this circumstance the invention provides forboth the audio compression element and audio decompression elementwithin the inventive article of 2-way A/V software the endpoint devicenot be enabled/initialized.

Additionally, various embodiments of the inventive concept also providefor automatic partition of a common article of software responsive todynamic needs. For example, in an internet browsing setting, varioustypes of mash-up configurations and other web-page situations maytrigger automatic partition of a common article of software as may beadvantageous for performance.

In one or more embodiments of the invention, software partitions mayform more complicated set and graph partitions than the simple exemplarycases suggested in FIGS. 42-44. This is possible even in the simplesttwo-section partitioning.

In one or more embodiments of the invention, a single terminal platformmay be used to access more than one server platform of the same kind, orof different kinds, at the same time. For such configurations, the samesoftware partitions may participate simultaneously in a hierarchicalarrangement for client-server interaction purposes, and peer arrangementfor the purposes of enabling optimal performance on a single terminal.One possible embodiment of this simultaneous multi-partitioning usessystem synchronization primitives and interprocess communication tocoordinate access to limited resources on the terminal.

In one or more embodiments of the invention, software versioning isanother important aspect of partitioning. An article or instance ofsoftware that evolves in time may result in partitions belonging todifferent versions of software interacting at a given moment. Factorscontributing to this include various hardware limitations (e.g.read-only permanent executable code storage) or software policies (e.g.,software configuration controls). The RMEP session above illustrates onepossible embodiment of a multi-version compatibility mechanism. Otherpossible mechanisms include automatic updates of software partitions;automatic repartitioning to provide the best feature set given softwareversion limitations; available feature set queries and negotiations.

16. DESCRIPTION OF EXEMPLARY COMPUTER HARDWARE PLATFORM

FIG. 50 is a block diagram that illustrates an embodiment of acomputer/server system 5000 upon which an embodiment of the inventivemethodology may be implemented. The system 5000 includes acomputer/server platform 5001, peripheral devices 5002 and networkresources 5003.

The computer platform 5001 may include a data bus 5004 or othercommunication mechanism for communicating information across and amongvarious parts of the computer platform 5001, and a processor 5005coupled with bus 5004 for processing information and performing othercomputational and control tasks. Computer platform 5001 also includes avolatile storage 5006, such as a random access memory (RAM) or otherdynamic storage device, coupled to bus 5004 for storing variousinformation as well as instructions to be executed by processor 5005.The volatile storage 5006 also may be used for storing temporaryvariables or other intermediate information during execution ofinstructions by processor 5005. Computer platform 5001 may furtherinclude a read only memory (ROM or EPROM) 5007 or other static storagedevice coupled to bus 5004 for storing static information andinstructions for processor 5005, such as basic input-output system(BIOS), as well as various system configuration parameters. A persistentstorage device 5008, such as a magnetic disk, optical disk, orsolid-state flash memory device is provided and coupled to bus 5004 forstoring information and instructions.

Computer platform 5001 may be coupled via bus 5004 to a display 5009,such as a cathode ray tube (CRT), plasma display, or a liquid crystaldisplay (LCD), for displaying information to a system administrator oruser of the computer platform 5001. An input device 5010, includingalphanumeric and other keys, is coupled to bus 5004 for communicatinginformation and command selections to processor 5005. Another type ofuser input device is cursor control device 5011, such as a mouse, atrackball, or cursor direction keys for communicating directioninformation and command selections to processor 5005 and for controllingcursor movement on display 5009. This input device typically has twodegrees of freedom in two axes, a first axis (e.g., x) and a second axis(e.g., y), that allows the device to specify positions in a plane.

An external storage device 5012 may be coupled to the computer platform5001 via bus 5004 to provide an extra or removable storage capacity forthe computer platform 5001. In an embodiment of the computer system5000, the external removable storage device 5012 may be used tofacilitate exchange of data with other computer systems.

The invention is related to the use of computer system 5000 forimplementing the techniques described herein. In an embodiment, theinventive system may reside on a machine such as computer platform 5001.According to one embodiment of the invention, the techniques describedherein are performed by computer system 5000 in response to processor5005 executing one or more sequences of one or more instructionscontained in the volatile memory 5006. Such instructions may be readinto volatile memory 5006 from another computer-readable medium, such aspersistent storage device 5008. Execution of the sequences ofinstructions contained in the volatile memory 5006 causes processor 5005to perform the process steps described herein. In alternativeembodiments, hard-wired circuitry may be used in place of or incombination with software instructions to implement the invention. Thus,embodiments of the invention are not limited to any specific combinationof hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing instructions to processor 5005 forexecution. The computer-readable medium is just one example of amachine-readable medium, which may carry instructions for implementingany of the methods and/or techniques described herein. Such a medium maytake many forms, including but not limited to, non-volatile media andvolatile media. Non-volatile media includes, for example, optical ormagnetic disks, such as storage device 5008. Volatile media includesdynamic memory, such as volatile storage 5006.

Common forms of computer-readable media include, for example, a floppydisk, a flexible disk, hard disk, magnetic tape, or any other magneticmedium, a CD-ROM, any other optical medium, punchcards, papertape, anyother physical medium with patterns of holes, a RAM, a PROM, an EPROM, aFLASH-EPROM, a flash drive, a memory card, any other memory chip orcartridge, or any other medium from which a computer can read.

Various forms of computer readable media may be involved in carrying oneor more sequences of one or more instructions to processor 5005 forexecution. For example, the instructions may initially be carried on amagnetic disk from a remote computer. Alternatively, a remote computercan load the instructions into its dynamic memory and send theinstructions over a telephone line using a modem. A modem local tocomputer system can receive the data on the telephone line and use aninfra-red transmitter to convert the data to an infra-red signal. Aninfra-red detector can receive the data carried in the infra-red signaland appropriate circuitry can place the data on the data bus 5004. Thebus 5004 carries the data to the volatile storage 5006, from whichprocessor 5005 retrieves and executes the instructions. The instructionsreceived by the volatile memory 5006 may optionally be stored onpersistent storage device 508 either before or after execution byprocessor 5005. The instructions may also be downloaded into thecomputer platform 5001 via Internet using a variety of network datacommunication protocols well known in the art.

The computer platform 5001 also includes a communication interface, suchas network interface card 5013 coupled to the data bus 5004.Communication interface 5013 provides a two-way data communicationcoupling to a network link 5015 that is coupled to a local network 5015.For example, communication interface 5013 may be an integrated servicesdigital network (ISDN) card or a modem to provide a data communicationconnection to a corresponding type of telephone line. As anotherexample, communication interface 5013 may be a local area networkinterface card (LAN NIC) to provide a data communication connection to acompatible LAN. Wireless links, such as well-known 802.11a, 802.11b,802.11g and Bluetooth may also used for network implementation. In anysuch implementation, communication interface 5013 sends and receiveselectrical, electromagnetic or optical signals that carry digital datastreams representing various types of information.

Network link 5013 typically provides data communication through one ormore networks to other network resources. For example, network link 5015may provide a connection through local network 5015 to a host computer5016, or a network storage/server 5017. Additionally or alternatively,the network link 5013 may connect through gateway/firewall 5017 to thewide-area or global network 5018, such as an Internet. Thus, thecomputer platform 5001 can access network resources located anywhere onthe Internet 5018, such as a remote network storage/server 5019. On theother hand, the computer platform 5001 may also be accessed by clientslocated anywhere on the local area network 5015 and/or the Internet5018. The network clients 5020 and 5021 may themselves be implementedbased on the computer platform similar to the platform 5001.

Local network 5015 and the Internet 5018 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link5015 and through communication interface 5013, which carry the digitaldata to and from computer platform 5001, are exemplary forms of carrierwaves transporting the information.

Computer platform 5001 can send messages and receive data, includingprogram code, through the variety of network(s) including Internet 5018and LAN 5015, network link 5015 and communication interface 5013. In theInternet example, when the system 5001 acts as a network server, itmight transmit a requested code or data for an application programrunning on client(s) 5020 and/or 5021 through Internet 5018,gateway/firewall 5017, local area network 5015 and communicationinterface 5013. Similarly, it may receive code from other networkresources.

The received code may be executed by processor 5005 as it is received,and/or stored in persistent or volatile storage devices 5008 and 5006,respectively, or other non-volatile storage for later execution.

Finally, it should be understood that processes and techniques describedherein are not inherently related to any particular apparatus and may beimplemented by any suitable combination of components. Further, varioustypes of general purpose devices may be used in accordance with theteachings described herein. It may also prove advantageous to constructspecialized apparatus to perform the method steps described herein. Thepresent invention has been described in relation to particular examples,which are intended in all respects to be illustrative rather thanrestrictive. Those skilled in the art will appreciate that manydifferent combinations of hardware, software, and firmware will besuitable for practicing the present invention. For example, thedescribed software may be implemented in a wide variety of programmingor scripting languages, such as Assembler, C/C++, Perl, Shell, PHP,Java, etc.

17. CLOSING

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theembodiments were chosen and described in order to best explain theprinciples of the invention and its practical applications, to therebyenable others skilled in the art to best utilize the invention andvarious embodiments with various modifications as are suited to theparticular use contemplated.

Moreover, other implementations of the invention will be apparent tothose skilled in the art from consideration of the specification andpractice of the invention disclosed herein. Various aspects and/orcomponents of the described embodiments may be used singly or in anycombination in the systems and methods for handling and implementationof real-time communications applications and other network-performancesensitive applications in a VDI environment. It is intended that thespecification and examples be considered as exemplary only, with a truescope and spirit of the invention being indicated by the followingclaims.

What is claimed is:
 1. A system for providing interactive two-way audioin a desktop virtualization environment, the desktop virtualizationenvironment comprising at least one desktop virtualization servercomputer and at least one desktop virtualization client endpoint devicewith an associated microphone element, the system comprising: a. atleast one instance of server software executing on the desktopvirtualization server and providing at least interactive user interfacefunctions to an associated desktop virtualization client endpointdevice; and b. at least one instance of endpoint software executing onthe desktop virtualization client endpoint device comprising a networkport, the at least one instance of endpoint software receiving anincoming real-time audio stream from the network port and providing atleast real-time and audio playback functions on the desktopvirtualization client endpoint device, wherein the at least one desktopvirtualization client endpoint is configured to: i. accept real-timeaudio input from a microphone element associated with the desktopvirtualization client endpoint; and ii. provide an outgoing real-timecompressed audio stream to the network port responsive to the real-timeaudio input from the microphone element.
 2. The system of claim 1wherein the incoming real-time audio stream is provided by a differentinstance of endpoint software executing on a different desktopvirtualization client endpoint device.
 3. The system of claim 1 whereinthe outgoing real-time audio stream is provided to a different instanceof endpoint software executing on a different desktop virtualizationclient endpoint device.
 4. The system of claim 1 wherein the real-timeaudio input from the microphone element is a compressed audio stream. 5.The system of claim 1 wherein the real-time audio input from amicrophone element is an uncompressed audio stream.
 6. The system ofclaim 5 wherein the instance of endpoint software includes an audiocompression algorithm, which performs audio compression to produce theoutgoing real-time compressed audio stream.
 7. The system of claim 6wherein the instance of endpoint software is configured such that,should the desktop virtualization client endpoint device comprise amulticore processor, the audio compression algorithm is executed on aspecific core of the multicore processor.
 8. The system of claim 5wherein at least one video compression function is provided by thehardware of desktop virtualization client endpoint device, and theinstance of endpoint software includes an interface for use inexchanging audio streams with the hardware of the desktop virtualizationclient endpoint device.
 9. The system of claim 1 wherein the instance ofendpoint software comprises a audio decompression algorithm.
 10. Thesystem of claim 9 wherein at least one video decompression function isprovided by the hardware of desktop virtualization client endpointdevice, and wherein the instance of endpoint software includes aninterface for use in exchanging audio streams with the hardware of thedesktop virtualization client endpoint device.
 11. A method forproviding interactive two-way audio in a desktop virtualizationenvironment, the desktop virtualization environment comprising at leastone desktop virtualization server computer and at least one desktopvirtualization client endpoint device with an associated microphoneelement, the method comprising: c. providing, using at least oneinstance of server software executing on the desktop virtualizationserver, at least interactive user interface functions to an associateddesktop virtualization client endpoint device; d. receiving, using atleast one instance of endpoint software executing on the desktopvirtualization client endpoint device comprising a network port, anincoming real-time audio stream from the network port and providing atleast real-time and audio playback functions on the desktopvirtualization client endpoint device; e. accepting, using the at leastone desktop virtualization client endpoint, real-time audio input from amicrophone element associated with the desktop virtualization clientendpoint; and f. providing, using the at least one desktopvirtualization client endpoint, an outgoing real-time compressed audiostream to the network port responsive to the real-time audio input fromthe microphone element.
 12. The method of claim 11 wherein the incomingreal-time audio stream is provided by a different instance of endpointsoftware executing on a different desktop virtualization client endpointdevice.
 13. The method of claim 11 wherein the outgoing real-time audiostream is provided to a different instance of endpoint softwareexecuting on a different desktop virtualization client endpoint device.14. The method of claim 11 wherein the real-time audio input from themicrophone element is a compressed audio stream.
 15. The method of claim11 wherein the real-time audio input from a microphone element is anuncompressed audio stream.
 16. The method of claim 15 further comprisingexecuting an audio compression algorithm, which performs audiocompression to produce the outgoing real-time compressed audio stream.17. The method of claim 16 wherein should the desktop virtualizationclient endpoint device comprise a multicore processor, the audiocompression algorithm is executed on a specific core of the multicoreprocessor.
 18. The method of claim 11 further comprising providing atleast one video compression function by the hardware of the desktopvirtualization client endpoint device, wherein the instance of endpointsoftware includes an interface for use in exchanging audio streams withthe hardware of the desktop virtualization client endpoint device. 19.The method of claim 11 wherein the instance of endpoint softwarecomprises a audio decompression algorithm.
 20. The method of claim 11further comprising providing at least one video decompression functionby the hardware of desktop virtualization client endpoint device,wherein the instance of endpoint software includes an interface for usein exchanging audio streams with the hardware of the desktopvirtualization client endpoint device.